[M3devel] using *context functions for user threading?

[Jay]

Tony, can you tell me more of what you have in mind here?
 
 
In particular...I /think/ it goes like:
 
 
use getcontext + makecontext to "create a thread"
use simple struct copying/memcpy of the third parameter to the signal handler for context switching
in particular -- setcontext/makecontext never used -- except to start a thread, but not to switch to/from already started threads.
 
 
?
 
 
Implication here is that even on systems without context APIs, our ucontext_t needs to match what the signal handler gets. That isn't the case for what I just got "working" (prototype, proof of concept, whatever) on OpenBSD, but easy enough.
 
 
An alternative is to call setcontext in the signal handler, but that makes me nervous.
It seems best to exit "cleanly" out of a signal handler?
 
And then I get to seeing very murky things, like, can a system call be interrupted by an alarm signal? If so, switching threads then...what would that do? Seems bad.
So then I guess I see the origin of all the original system call wrappers -- to turn of thread switching during system calls.
 
 
?
 
 
The current code does appear to longjmp out of a system call -- or rather, to longjmp from one alarm signal to another. Again this seems confusing if alarm signals can interrupt system calls.
 
 
Some abstraction that encompasses Win32 fibers might be nice, though there would remain the question of how to preempt.
 
 
 - Jay