Re: gthread-win32.c

[Steven Brooks <umbrook0 cs umanitoba ca>]

Kaz Kylheku wrote:

> >  My suspicion is you need a thread to manage the other threads.  It uses
> >  suspends and resumes to control them, and all event requests go through
>
>
> There is no reliable way to control another thread with suspends and
> resumes, because you have no idea what it's doing. This type of
> technique is best left to debuggers and garbage collectors.

Actually, you can know what it was doing.  For example, after signalling
``make me wait on this event'', it would enter a while loop examining a
volatile variable which the event manager controls.  It would be
suspended while in this while loop, and woken up with the variable
changed so it would exit the while loop and continue executing:

wait_for_event(event):
	1. volatile var <- true
	2. msg <- { this_thread, "wait-for-event", &event, &var }
	3. send msg to manager
	4. while var
		5. give up timeslice

Obviously, var would not actually be on the stack (since stacks are not
shared between threads).

However, your idea sounds more promising anyway.  One concern is, how
do you get rid of the race condition between when a thread adds itself
to the queue and when it waits on its own event?  Unless you make the
thread events manual-reset, you still have the potential for a lost
event.

Steven