Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 09 Nov 2005 15:58:30 +0100

Your fix works perfectly.

HP-UX returns:

creek: .../base/3-14-X > bin/hpux-parisc/blockingSockTestHost
../blockingSockTest.cpp: server circuit was disconnected

../blockingSockTest.cpp: client circuit socket recv() error was

"Interrupted system call"

The local OS behaves like "esscimqi_socketSigAlarmRequired".
The epicsSocketSystemCallInterruptMechanismQuery() function returns
"esscimqi_socketSigAlarmRequired".

while my Linux box says:

aragon: .../base/3-14-X > bin/linux-x86/blockingSockTestHost
../blockingSockTest.cpp: server circuit was disconnected
../blockingSockTest.cpp: client circuit was disconnected
The local OS behaves like "esscimqi_socketBothShutdownRequired".
The epicsSocketSystemCallInterruptMechanismQuery() function returns
"esscimqi_socketBothShutdownRequired".

which is quite what I would expect these two to return.

Thanks!

Ralph

Jeff Hill wrote:

Ralph,

This test isnt quite the same as the others as it is documenting differences
between the various OS implementations of sockets and testing how well we
are able to deal with them.

That test was written to document what is required to interrupt a thread
blocking in socket recv() on the various OS. It looks like the code was
presuming that a CA server was running on the local host, and would not work
otherwise. There is also code there to startup a local server. I went ahead
and instantiated that code and committed it. The test should run standalone
now.

Nevertheless...

O strange behavior could result if a CA server is already running on the
local host when the test starts.
O strange behavior could result if the local os does not allow the process
to exit if a thread is stil running when main exists (I didn't see any
problems with this on linux or windows).

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System