Hi Till,
So I agree that a function like epicsMutexMustLock() is only useful for C programmers that prefer not to write error recovery code. I also agree that, given a variety of approaches to design, two functions are needed, and that another reason for the version that returns status is that the C++ programmers will write a wrapper function that converts failure status to an exception. They will have the best situation; minimal extra source code for the error code checking, and also a better potential for recovery.
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Till Straumann
> Sent: Tuesday, February 01, 2011 8:28 PM
> To: [email protected]
> Subject: Re: epicsEvent (posix implementation) bug ?
>
> 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
- References:
- epicsEvent (posix implementation) bug ? Till Straumann
- Re: epicsEvent (posix implementation) bug ? Eric Norum
- Re: epicsEvent (posix implementation) bug ? Andrew Johnson
- Re: epicsEvent (posix implementation) bug ? Andrew Johnson
- Re: epicsEvent (posix implementation) bug ? Till Straumann
- Navigate by Date:
- Prev:
RE: Trouble with mcaR6-12-4 and EPICS 3.14.12 (cygwin-x86) Mark Rivers
- Next:
epics 3.14.12 and readline 5.1 Matt Rippa
- 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
- Navigate by Thread:
- Prev:
Re: epicsEvent (posix implementation) bug ? Till Straumann
- Next:
Motor driver for Parker Hannifin ACR series controllers? Mark Rivers
- 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
|