[omniORB] Hanging during boa->destroy()

[Sai-Lai Lo]

The fix is now back-ported to the omni2_8_develop branch. You can obtain
the snapshot of this tree at:

ftp://ftp.uk.research.att.com/pub/omniORB/omniORB_28_snapshots/omniORB-latest.tar.gz

Sai-Lai

>>>>> Christof Meerwald writes:

> On Tue, 28 Nov 2000 18:54:28 -0500, Gerke, Tom wrote:
> [...]
>> call boa->impl_shutdown() and then boa->destroy().  This boa->destroy() call
>> hangs up for about 3 minutes before exiting.  No exception is thrown, and
>> when it comes out, my application proceeds to exit normally.
> [...]
>> It's stuck in a call to tcpSocketMTincomingFactory::removeIncoming(), when
>> the pd_shutdown_cond object (of type omniCondition) calls wait...   It's the
>> "WaitForSingleObject(xxx, INIFINITE);" call inside of omniCondition::wait()
>> which is keeping me held up for those minutes.

> I think this behaviour is fixed in omniORB 3.0.2; here is the relevant
> change-log entry (from tcpSocketMTfactory.cc):

>   Revision 1.22.6.17 2000/08/10 10:10:56 sll
>   For those platforms which cannot be unblocked from a recv() by a
>   shutdown(), now do poll() or select() for both incoming and outgoing
>   strands.  This is necessary especialy for win32 or else the server side
>   socket will not shutdown until the client side close the socket. This
>   wasn't done previously as it was thought that shutdown() does have an
>   effect on recv() if this is a passive socket. This turns out to be wrong.




-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND