Re: Problems with shutdown of crserver for non-tcpip connections

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?

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


> 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


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click