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

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

Brian Paul wrote:
> I do not see that.  Are you sure one of the crserver processes isn't 
> lingering around from a previous run?

Definitely not.  I've been painstakingly killing them, and all the crservers 
in the batch I'm looking at have consecutive PIDs.  The 2 children list the 
first crserver as their parent.
 
> 
> > Is this maybe somehow a consequence of 
> > having compiled in teac communication, even if it is not used?
> 
> Perhaps.  I can't run/test the teac/GM stuff here.
> 
> -Brian

-Joel

> Joel Welling wrote:
> > Brian Paul wrote:
> >>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.
> >>
> > 
> >>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?
>