ez-cdda sleep

[James Hawkins]

> I don't think it will be easy to fix.

heh yea this sounds like a difficult one.  Way beyond me.


On Sat, 02 Oct 2004 15:44:08 +0200, Eric Pouech <pouech-eric at wanadoo.fr> wrote:
> > I would investigate whether it is supposed to be in the middle of a
> > blocking call and under what conditions it should return from it.
> I got a look at it.
> 
> Basically, what happens is:
> - the entry point code just loops onto itself
> EntryPoint: jmp EntryPoint
> 
> - so, the creator of this program is likely to wait for the child to be
> looping on EntryPoint before going any further (wait until init is done,
> and entry point is called)
> - however, when one thread calls SuspendThread on another thread (which
> is in running state), the later thread gets a USR1 signal. The signal
> handler for USR1 will wait on the server until the thread is resumed.
> 
> But, the address we get in GetThreadContext is the one from where the
> thread waits on the server (hence the 0xffffe410 address), not the
> address it was suspended from (as it's supposed to be) (the entry point
> address).
> 
> I don't think it will be easy to fix.
> 
> Possible ideas:
> - implement suspend/resume in processes without any specific code. We
> dropped that long ago for stability issues (and race condition removal
> as well)
> - cheat for context reading in server while suspended. it will require
> some surgery (getting whether we are in the condition of this program,
> getting back to the signal handler, getting the signal context from the
> stack, grab the real EIP from it). Doable, but very hard to maintain
> (code in server, will depend on how signal handlers are written in
> ntdll, code will be CPU specific...)
> - storing context in server while entering USR1 signal handler (to be
> done without races, which will require some more work, as the server
> doesn't synchronize with the USR1 handler)
> 
> Nice can of worms :-/
> 
> A+
> 



-- 
James Hawkins