1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: epicsEvent (posix implementation) bug ? |
From: | Till Straumann <[email protected]> |
To: | [email protected] |
Date: | Tue, 01 Feb 2011 21:27:31 -0600 |
I probably have a little different take than Jeff. While giving the user of 'epicsEventWait()' a 'bad' error status back offers the opportunity to react to an error it also burdens the user because he/she then has to check a return code to make sure that a seemingly trivial operation suceeds. E.g., when I take a mutex I don't always want to have to check a return code. Often, I consider the case of failure when taking a mutex a fatal error. Either due to a programming error (e.g. an invalid mutex ID) or lack of system resources. Either way, I consider the possibility of failure with a need for graceful recovery marginal and the added effort to implement such a recovery too expensive. However, I also don't want to just take the mutex w/o making sure I really own it because that would leave a critical section exposed. Therefore, I really love epicsMutexMustLock() (even though it's implementation using 'assert' is flawed since 'assert' becomes a no-op if you compile with the symbol NDEBUG defined -- assert should IMHO replaced by cantProceed). Long story short - I'd suggest to provide two interfaces epicsEventWait() and epicsEventMustWait(). Regarding the posix implementation I consider the operations of taking/releasing the mutex associated with the condition variable of the class 'mustSucceed' since this mutex is entirely 'owned' by the implementation. If epicsEventWait() returns anything this should be the return value of 'pthread_cond_wait()'. -- Till On 02/01/2011 01:54 PM, Andrew Johnson wrote:
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