[omniORB] Re: ORBscanGranularity == shutdown time

[Felix Nawothnig]

Replying to a rather old mail from this list... Quoting Duncan:

> [..] I was forgetting that on Windows and HPUX, the recv()
> system call (and other related calls) is not interrupted when the
> underlying socket is closed. Therefore, omniORB uses a select() call
> with a timeout of the scan granularity instead.
> I'm not aware of any other way it could be done. If anyone knows how
> to do it, in a way that doesn't terribly uglify the code, please let
> me know.

I've been digging along the sources in that area - actually due to a
different issue, with app. verifier (win32 thing) enabled shutdown often
throws exceptions about invalid handles passed to a select() call on
connection shutdown due to a semi (?) race-con in
SocketCollection::Select() - when I found that mail.

Vaguely related - SocketCollection::Select() uses a pipe to wake the
select() call under some circumstances (not on Win32 - but the timeout is
small so the impact isn't that nasty *cough*), the same thing could
obviously be used in tcpConnection::Recv() - but not on Win32. :-)

On Windows instead one could utilize WSAEventSelect() and
WSAWaitForMultipleEvents() instead of the select() - the latter should
also accept all other kinds of synchronization primitives (say an event).
I'm not yet familiar enough with the code in question to say whether or
not it's feasible to introduce another synchronization mechasism between
whatever code paths close the sockets and tcpConnection::Recv()...

(Yea, I'm really lost here right now - if you used Visual Studio's "jump
to declaration / definition" and "search whole solution" features for 2
years it's hard to start thinking by yourself again. Maybe I'll just
create a dummy project :-)

Doesn't solve my original "invalid handle" exception though. Do you know
whether this is behaviour (selecting fds which may have been closed) is
intended?

On a second note - as I'm trying to get my shutdown right I noticed an
issue with the patch I sent - I was kinda overeager with the
notifications, calling the interceptor after the ORB was shutdown is not
really helpful... as a following work_pending() call yields
BAD_INV_ORDER... so I removed those calls again.

Cheers,

Felix