Martin Sustrik
Martin Sustrik
Nope. It's cooperative multitasking. If a coroutine doesn't want to yield, there's no way to force it to do so.
Generally, the OS provides that. Look at pthreads library.
The problem is that libdill socket layer can (and does) do some buffering itself. Thus, when you extract the underlying socket it can be in an inconsistent state, without libdill-layer...
That's useful. Thanks! There is no plain "wait" methods for unbundled gos: unbundled go actually creates a bundle with a single coroutine inside. You can thus wait on the returned...
wait: I prefer to be C-idiomatic, i.e. user has to handle cleanup manually. hclose: Yes, you shoud. I'll check the test code later on. Yes, multiple coroutines can wait on...
I don't follow. No, wait does not clean up, hclose does. Wait just waits till everybody's finished. When I was speaking about manual cleanup it meant the C-idiomatic way of...
Ah, I see you problem. go() is just a shortcut for bundle()+bundle_go() so you can do this: ``` h = go(fn()); bundle_wait(h); ```
Fair enough. I'll add that wording.
Broadcast is out of scope for libdill. You can build it on top though.
Why do you care about when exactly the context switch happens? Isn't it enough to know that it will happen eventually?