[M3devel] using *context functions for user threading?

[Tony Hosking]

On 31 Jan 2009, at 09:49, Jay wrote:

> Tony, can you tell me more of what you have in mind here?

I didn't plan anything other than using swapcontext instead of longjmp  
in switch_thread, and using makecontext instead of InitContext to get  
a forked thread's context.

> 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

No, swapcontext.

> in particular -- setcontext/makecontext never used -- except to  
> start a thread, but not to switch to/from already started threads.

Right.

> ?
>
>
> 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.

I don't know what you are saying here.  swapcontext should be 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?

You're right, but this is probably broken for the current longjmp- 
based implementation too.

> 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.

Yes,  I was never convinced that the longjmp-based implementation was  
safe either.  I figured that it probably worked only because it was a  
single-threaded process, but I don't know if that really prevents a  
timer signal arriving inside the signal handler, and what impact that  
might have.

> So then I guess I see the origin of all the original system call  
> wrappers -- to turn of thread switching during system calls.

No, those were only for GC.

> ?
>
> 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.

Right...

> Some abstraction that encompasses Win32 fibers might be nice, though  
> there would remain the question of how to preempt.

The safest solution for all of this is to have the timer signal  
handler set a flag and for the M3 compiler to inject a test of the  
flag at calls/backward branches, and explicitly yield if the flag is  
set.

>
>
> - Jay