24

Coroutines never left, they were just overshadowed by other things in the meanwhile. The recently increased interest in asynchronous programming and therefore coroutines is largely due to three factors: increased acceptance of functional programming techniques, toolsets with poor support for true parallelism (JavaScript! Python!), and most importantly: the ...


19

First of all, the actual requirements should drive the decision behind what language, frameworks and tools to use. If the requirements allow you to work on similar languages, frameworks and tools, then you should definitely try to keep things as consistent as possible. You want to keep things similar for the following reasons: Less context switching ...


15

It was done in the GetMessage call. The heart of a windows application is something like: while(GetMessage(&Msg, NULL, 0, 0) > 0) { TranslateMessage(&Msg); DispatchMessage(&Msg); } Each iteration gets a message and dispatches it. If there isn't a message available, it blocks until a message is available. Under 16-bit windows, the ...


10

For these types of things, I recommend that you file a defect, issue or an enhancement request as appropriate so that it can be tracked, scheduled if need be, and not forgotten. Get your primary and most important work done before you start tackling the extra. Not only does this help ensure you hit your own deadlines, it also gives others a chance to ...


8

Coroutines are generators - they just have the extra ability to receive arguments after invocation. Data pipelines (ETL stuff) are a bad example to show off their strengths. Pipelines rarely need the full power of coroutines - the data is static and unchanging, and does not need dynamic modification outside the context of your data and the encapsulating ...


6

There's a number of factors to consider like due dates for projects, visibility to management, impact on the business, etc. Generally though, I worked effectively with some rules I used: Break it down by feature/bug we'll call them tasks. This implies that you're using some kind of task tracking mechanism, which you must due to the hopping from project-to-...


6

Coroutines used to be useful because operating systems did not perform pre-emptive scheduling. Once they started providing pre-emptive scheduling, it was longer necessary to give up control periodically in your program. As multi-core processors become more prevalent, coroutines are used to achieve task parallelism and/or keep a system's utiliztion high (...


5

On a computer with a single cpu core, must a multithreading program be implemented based on an OS? No. A program can implement its own threading and scheduler. At this point, however, the program is taking on the role of an operating system, in that in the absence of a proper operating system kernel, the program must implement all of the hardware ...


5

I'm not sure for you, but for me Automatic Tests (Unit tests if possible) are a good way of discovering how the code works, and knowing that it doesn't work as expected. Automatic Tests replaces debugging, changing a memory-backed developer-checked knowledge and verification, to a file-backed explicitely-checked one. When coming back to your work later on,...


4

Preface I want to start of by stating stating a reason why coroutines aren't getting a resurgence, parallelism. In general modern coroutines are not a means to achieve task based parallelism, as modern implementations do not utilize multiprocessing functionality. The closest thing you get to that are things like fibres. Modern Usage (why they are back) ...


4

Early systems used coroutines to provide concurrency primarily because they are the simplest way of doing it. Threads require a fair amount of support from the operating system (you can implement them at a user level, but you will need some way of arranging for the system to periodically interrupt your process) and are harder to implement even when you do ...


3

The feature you are looking for is "fibers," sometimes called "cooperative threads." A fiber has its own stack, but you switch them in-and-out of threads cooperatively. Any one fiber can call a function, typically called yield, and pass the fiber that they wish the computer to execute on this thread. Only one fiber executes at one time on a given thread, ...


3

I feel your pain and find myself in that situation a lot. I try and do that small stuff "as time allows", but that's very vague. To the question of how to approach the situation: Triage them is my approach. You take a quick look - very quick - and it gets classified as Emergency, Urgent, Routine or Minor. I often do this list/log in excel. Emergencies ...


3

or maybe they are Honestly, of course they are. No doing so would be a complete waste of a multi-core machine. Occam's Razor applies here: the simplest explanation is correct.


3

Let them go. Concentrate on the bigger things. You'll end up wasting half your time on unimportant things. It's not a bad thing to work on a smaller issue itself, but it could be if you end up missing out on the more important stuff. Get comfortable with your own personality so that you are aware of this tendency. Don't beat yourself up about it, don't ...


3

Assuming these decisions have passed the "use the right tools for the job" stage, and you're genuinely faced with a situation where there are equally useful projects with equally useful tools for each that the developer knows, my thoughts: I have rarely, if ever, found myself benefitting from working in two entirely different mindsets at the same time. Some ...


2

for working on multiple, complex projects, regardless of whether they involve developing software, there's no substitute for writing things down. I've used bug tracking software, spreadsheets, personal wikis, a self-developed database, and probably a dozen other methods I've forgotten over the years. Writing things down helps you recall not only what you ...


2

I setup a task with a reminder for two reasons: I need a prompt to return to the code. I can enter any notes or link to important documents, web pages, files, etc.. It's difficult to switch tasks if you're in constant fear of forgetting to back to that original bug. You do need to have some idea of when it is best to set the reminder. I also do this when ...


2

You should strive to use the best tools for the job at hand. However, if the best tools' usage are utterly unknown to the developers these may not be the best tools.


2

An easy and readable way to switch between the PID tasks is to use a function pointer, like this: void (*pid_task)() = &task_pid_tune; int main() { //... startup code while( wait_for_timer_tick() ) { task1(); task2(); task3(); task4(); pid_task(); } } void task_pid_run() { //... run the PID } void task_pid_configure() { ...


2

The notion of whether or not software can do something without an OS is not really meaningful. An OS is software, and really the only thing that distinguishes an OS from other software running on a computer is that (at least in most modern multitasking systems) the OS reserves certain kinds of operation to itself and prevents other software from performing ...


2

Aside from the explicit request to Yield(), there are other APIs provided by Windows which potentially have to wait for another process to provide an answer, like the heart of the message pump GetMessage(), asking a window for information with SendMessage() and many more.


1

No, that is not possible. On the CPU/OS level, multitasking is executed on the level of threads. The OS gives time to various threads, but doesn't know about the (more granular) concept of tasks.


1

If you move that process to it's own core that has no processes running on it then it should take one second to complete correct? It's worth noting that this is in fact correct. Now, most OS's are smart enough to move threads around between cores (even single threaded applications - as long as they never execute on more than one thread at a time) to ...


1

A single-core CPU is like having just yourself to do whatever work has to be done. If you have four processing-intensive jobs that take a minute each to do, they'll take four minutes in aggregate to finish. You could work each until it's finished and go on to the next one or, if there has to be steady progress on each, you could do a bit of the first, a ...


1

My initial response is that if you have a team, why are you working like you don't? Certainly, there may be a reason, but I am not sure it is stated. Limiting Factors My suggestion is that you organize work to field as much product as early as possible and with the greatest possible profit margin. How you do this may depend on your business model and a ...


1

If these are multiple projects at your job or for your own business, its probably better to use a similar stack of technologies to enhance the chance of being able reuse parts of one in the other. BUT, if one project is for work, and one is a personal project you are doing at home - that is, two completely different venues - then use separate technologies. ...


1

That depends on what you want. If you want to get as much work done as possible - choose similar technologies, to minimize learning time. If you want to learn new things, choose different technologies, to increase exposure to new ideas and technologies. So it would depend on context. If it were a hobby project, I'd probably lean towards option 2, because ...


1

On one hand, sure, for obvious reasons (less context switching, more consistency, etc.) On the other hand, do you want to put all your eggs in one basket? What if the framework / platform / whatever of your choice somehow dies? What if the framework / platform / whatever that you didn't choose starts thriving? It does happen all the time, for example, with ...


Only top voted, non community-wiki answers of a minimum length are eligible