Re: gthread-win32.c

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:

	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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]