Re: [Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

[Joel W. <we...@st...>]

Brian Paul wrote:
> I don't know how the crserver would be spawning any threads.  The 
> crserver itself isn't even thread-safe.
> 
> Are you sure the GM library isn't creating the threads?
> 
> -Brian

teac.c isn't doing it directly, but it could be a side effect of the message 
buffer management code which is common to teac.c and (say) GM.

If I use a .conf file with only tcpip connections, crserver still spawns a 
second process; it's easy to see this with a 'ps'.  The process starts up 
immediately after crserver starts up, before the SPU network is fully 
established.  Do you not see this?  Is this maybe somehow a consequence of 
having compiled in teac communication, even if it is not used?

-Joel

> Joel Welling wrote:
> > Hi folks;
> >   I'm encountering a problem managing the crserver processes for configs in 
> > which I use the teac network mechanism; I think it will also be seen in things 
> > like GM.  When I spawn the crserver I keep track of its PID, and when I want 
> > it to terminate I send a TERM signal to that PID.  Fair enough; the process 
> > that got that signal terminates, running through the 'teardown' routine in the 
> > crserverlib code.
> >   The problem is, by this time the crserver has spawned 2 child processes.  I 
> > believe they are actually other threads, but I'm not sure- I know they are not 
> > being created with crSpawn().  One of those threads is very, very busy doing a 
> > wait loop, waiting for messages on my high-bandwidth network.  That process, 
> > and the third process which is its child, do *not* die when their parent (the 
> > originally spawned process) gets the TERM signal.
> >   Can anyone confirm for me that these are threads, and tell me which bit of 
> > code is likely to be spawning them?  Are their PIDs or thread IDs getting 
> > saved anywhere?  I can modify the teardown procedure to kill them if I have 
> > their names, but I can't simply kill the whole process group- that kills 
> > innocent bystanders.
>