Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <[email protected]> · Mon, 8 Jul 2019 20:05:19 -0700

Sorry for the stream of consciousness (aka ramble).  I've been digging into
this all day.  I thought I'd see if anyone else has run across
this situation before.

Looking into socket cleanup race conditions for
https://github.com/epics-base/pvAccessCPP/issues/149
has led me down an unexpected path.

In the process of understanding what actually go on when a
TCP connection is closed, and it's two worker thread exit,
I noticed a unit test hang.  I found that on RTEMS 4.10 (at least)
the worker thread handling TCP accept() apparently not being interrupted
correctly.  It's still in accept() after close() has returned in the other thread.

I noticed that the code trying to interrupt calls shutdown(fd, SHUT_RDWR)
and then immediately calls close(fd).  The calling thread has higher priority
than the worker.  I add a sleep 1 in between these two socket calls and the
accept() is interrupted and the worker returns.

That this hangs may well be an RTEMS bug, though it might be argued to be
undefined behavior.  It does seem to me like a race to close() when a
concurrent thread may be preparing to, or in the process of, calling eg. recv(),
accept(), or similar.

If so, how to avoid this without a redesign?  *

In the esscimqi_socketBothShutdownRequired cases (not winsock) I imagine
that the correct resolution is to shutdown(), then join the workers,
and finally to close().

What about Windows where only close() is called?  aka. esscimqi_socketCloseRequired

* eg. use select()/poll(), including a dedicated pipe() to cleanly interrupt

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System