[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: DEBUG_ONLY_THIS_PROCESS
From:       Eric Pouech <Eric.Pouech () wanadoo ! fr>
Date:       1999-11-30 18:04:51
[Download RAW message or body]

Ulrich Weigand wrote:
> I think we should provide some (more or less) safe way to effect
> Wine client-side process termination actions (clean up TASK, PDB,
> 16-bit global memory, etc., and also notify USER).  The obvious way
> to do that would be via a service thread callback, but this doesn't
> work at the moment as the service thread is killed with all the others ;-)
> 
> What do you think of making the notion of 'service thread' explicit
> on the server side, and have the server treat the service thread
> specially?  This could e.g. mean that it never sends a SIGTERM to
> the service thread, but performs a callback (either by signalling
> a handle the thread waits on, or by scheduling an APC) that causes
> the service thread to terminate itself after performing appropriate
> cleanup ...
well, this may need to be extended some way. So far, we could classify
the threads in two parts:
- the process' threads (as created by the process itself) (I'd name them
client threads)
- the threads created by Wine, for its own purpose. the service thread
is one of them, but there are others (e.g. there are a couple of them spread
across the multimedia DLLs for asynchronous playback)(those could be name wine 
internal threads - system thread is already used on NT and has some other
meaning)

It may be a good idea to be able to distinguish the two parts. For example, 
we shall end a process when its last client thread dies, not when its last
client or wine internal thread dies (Ulrich pointed that out for service thread
I just want to stress out service thread may not be the only thread in cause)

as all those wine internal threads are attached to process wide object (the PDB
for the service threads), (play back action requested the process...), their
destruction has to be taken care off on PROCESS_DETACH, not THREAD_DETACH, which
leads the clean up of those objects (and wine internal threads) an open
question (unless we tag/mark/count the Wine internal threads)

just my two cents (of euro)

A+
-- 
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle


=========================================================================

[prev in list] [next in list] [prev in thread] [next in thread]