Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 1 Feb 2011 13:54:24 -0600

The current Posix implementation of the epicsEvent API contains many uses of 
its local checkStatusQuit() macro to detect and handle situations where the 
OS' pthread routine returns an error — it prints an error message, then calls 
cantProceed() which halts the thread.  In some cases the API leaves little 
choice on what /can/ be done, for example the epicsEventSignal() routine 
returns void, so there is no way to signal a fault up to the caller.

In other cases though we can return an error, and I'm working on changing some 
of the internals to just print a warning message and do that instead.  For 
example, epicsEventCreate() is allowed to return NULL; epicsEventMustCreate() 
is provided for users who don't want to handle failures themselves.

That leaves a few additional cases: epicsEventDestroy() warns but continues if 
either of the pthread_xxx_destroy() routines complain, which seems sensible 
(it may leak memory, but we have reported something).

The interesting question (the main purpose of this message) is what to do if 
pthread_mutex_unlock() returns an error at the end of the epicsEventWait() 
routines.  Currently the code uses checkStatusQuit() so will halt the thread, 
unlike the other implementations.

A discussion on what the epicsEvent routines should do on getting an error 
from the OS routines is welcome (but Argonne is about to shut down for a 12"+ 
snow-storm so don't expect an immediate response from me).

- Andrew
-- 
If a man is offered a fact which goes against his instincts, he will
scrutinize it closely, and unless the evidence is overwhelming, he will
refuse to believe it.  If, on the other hand, he is offered something
which affords a reason for acting in accordance to his instincts, he
will accept it even on the slightest evidence.  -- Bertrand Russell

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System