Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: Concerns about link-support-2 branch
From: Michael Davidsaver <mdavidsaver@gmail.com>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: EPICS core-talk <core-talk@aps.anl.gov>
Date: Wed, 8 Mar 2017 19:50:19 -0500
On 03/08/2017 05:44 PM, Andrew Johnson wrote:
> ...
>> I don't like the existing behavior of the dbGet*() calls.  I've realized
>> that the code I've been writing is open to race conditions w/ CA_LINK.
>> I want to see this "fixed".  I agree that fixing dbCa.c is out of scope
>> for your branch.  However, I think that such a fix will be complicated
>> by introducing another layer of public API.
> 
> Maybe not.

Well, I think that having to add another member to the lset struct does
rather illustrate my point ;)

> Does the attached patch add sufficient functionality for your needs? I
> haven't tested it yet, but I think the basic functionality is right.

Sort of... maybe.  Perhaps you could give it a spin in an actual device
support?  How would you use this to replicate my aSub which returns the
first non-INVALID input?  I'm interested how/if you can avoid copying in
the input values twice (minor for scalars, not so far arrays).

> ...
> I prefer using a callback to providing direct access to a link's
> lock/unlock capabilities, it's harder for user code to leave a link
> locked this way. Link types that provide an lset::doLocked() method must
> use a recursive mutex for locking.

It's nicer for C code.  Less so for C++, where lack of exception
handling could leave the mutex locked.  It also allows user code the
"opportunity" to do extra work with the lock held (eg. unit conversion).

I haven't decided whether I like this more or less than that "options"
API of dbGet().  It's more type safe, but also more verbose and
non-linear (as in execution flow).


Replies:
Re: Concerns about link-support-2 branch Andrew Johnson
References:
Concerns about link-support-2 branch Andrew Johnson
Re: Concerns about link-support-2 branch Michael Davidsaver
Re: Concerns about link-support-2 branch Johnson, Andrew N.
Re: Concerns about link-support-2 branch Michael Davidsaver
Re: Concerns about link-support-2 branch Andrew Johnson

Navigate by Date:
Prev: Re: Concerns about link-support-2 branch Andrew Johnson
Next: Re: Concerns about link-support-2 branch Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Re: Concerns about link-support-2 branch Andrew Johnson
Next: Re: Concerns about link-support-2 branch Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 09 Mar 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·