Re: 3.14.8: blockingSockTest - assert() fails.

[Ralph Lange <Ralph.Lange@bessy.de>]

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
>