Re: Coroutines, goroutines

> I'm going to guess that movable stacks are out of scope for this 
> project —
> or maybe not possible at all, in the presence of FFI — but here's 
> another
> idea.  When a fiber is created, we allocate it a single 4kB stack page,
> placing the mprotect'ed guard page next to it, but we spread these out 
> in
> address space at, say, 256kB intervals (configurable).  Then when the 
> guard
> page is hit, we can grow the stack without moving it.  This way, at 
> least
> we don't use up much physical memory for a fiber by default.  Does this
> make sense?

You'll need 252kB of guard pages to make sure
that nothing else allocates in there.

As for another data point, the default "ulimit -s"
(stack size, used by pthreads) is 8MB
on Debian testing with a 6.17.9+deb14-rt-amd64 kernel
(though I have to admit that I didn't try to find out
where that comes from, /etc/security/limits.conf is empty).


Also, I'd hope that coroutines/fibers either hide
behind a compile-time flag or have (nearly) no performance impact --
it sounds to me as if most of IO and locking (including futex support)
function have to be modified.


Other discussion points that I didn't see mentioned yet:
- Fairness (depends on the cooperativeness of fibers, I guess)
- CPU resp. IO priorities (a socket might be more important than a file)
- Lock passing between fibers/pthreads
- Not all IO syscalls can be used non-blocking (fdatasync),
   resp. not all variants (accept4) are available everywhere


_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel