3 ms·

It creates a stack per coroutine and if the coroutine would block, it switches to another coroutine instead. As for threads, it's single threaded (yet concurre

by rumcajz 11y ago

It creates a stack per coroutine and if the coroutine would block, it switches to another coroutine instead. As for threads, it's single threaded (yet concurrent). If you want to take advantage of multicore machines, there's a step in the tutorial about that: http://libmill.org/tutorial.html#step7 http://libmill.org/tutorial.html#step7

infogulch 11y ago
One of the reasons goroutines are considered 'lightweight' is that they allocate a small stack to begin with which is reallocated and moved if more space is needed. Of course, stack-moving isn't possible in C for various reasons. What does libmill do here? Does it allocate a large stack right off the bat? What happens in a stack overflow, does it segfault or will it just trample over whatever is beneath it? Edit: an ounce of investigation is worth a pound of answered questions, or something like that. It appears stack sizes are configurable, but default to 256kb [1] (for scale, go defaults to 2k), and are retained in a cache of size 64 [#L72] (by default). Also the bottom page is used as a stack guard if posix and mprotect are available [#L90]. From a cursory glance there appears to be some data races in the stack allocation code, though I could be mistaken. E.g. stack.c#L137 [1]: https://github.com/sustrik/libmill/blob/master/stack.c#L47 https://github.com/sustrik/libmill/blob/master/stack.c#L47
- evmar 11y ago
  Note that large stacks only use address space, not memory, so it's not such a problem (especially on 64-bit). I've never used libmill but from a glance at the docs it appears they suggest using multiple processes for parallelism, not multiple threads, so there is no such thing as a data race.
- rumcajz 11y ago
  I don't think there's a data race, given that the whole thing is single-threaded. Multiple processes should be used for parallelism (see step 7 of the tutorial). As for the default stack size, it's hard (but doable) to work with smaller stack size in C. For example, humble printf() can allocate a buffer several kB long on stack.

by rumcajz 11y ago

infogulch 11y ago

One of the reasons goroutines are considered 'lightweight' is that they allocate a small stack to begin with which is reallocated and moved if more space is needed. Of course, stack-moving isn't possible in C for various reasons. What does libmill do here? Does it allocate a large stack right off the bat? What happens in a stack overflow, does it segfault or will it just trample over whatever is beneath it? Edit: an ounce of investigation is worth a pound of answered questions, or something like that. It appears stack sizes are configurable, but default to 256kb [1] (for scale, go defaults to 2k), and are retained in a cache of size 64 [#L72] (by default). Also the bottom page is used as a stack guard if posix and mprotect are available [#L90]. From a cursory glance there appears to be some data races in the stack allocation code, though I could be mistaken. E.g. stack.c#L137 [1]: https://github.com/sustrik/libmill/blob/master/stack.c#L47 https://github.com/sustrik/libmill/blob/master/stack.c#L47

evmar 11y ago
Note that large stacks only use address space, not memory, so it's not such a problem (especially on 64-bit). I've never used libmill but from a glance at the docs it appears they suggest using multiple processes for parallelism, not multiple threads, so there is no such thing as a data race.
rumcajz 11y ago
I don't think there's a data race, given that the whole thing is single-threaded. Multiple processes should be used for parallelism (see step 7 of the tutorial). As for the default stack size, it's hard (but doable) to work with smaller stack size in C. For example, humble printf() can allocate a buffer several kB long on stack.