Experimental Physics and
Industrial Control System

[email protected] (William Lupton) · Fri, 6 Nov 1998 10:22:34 -1000

Dear all,

Re the putCallback SNL discussion, William Lupton wrote:
>> Off the top of my head, how about the following spec:
>> 
>> pvPut( var );		/* existing behavior */
>> 
>> pvPut( var, wait );	/* use ca_put_callback(); if wait==TRUE, block on
>> 			   completion with some pre-determined timeout */
>> 
>> pvPut( var, wait, timeout );
>> 			/* as above but specify the timeout */
>> 
>> if wait==FALSE, pvPut() will not block and completion can be checked by using
>> 
>> when ( pvPutDone( var ) ) {
>> }
>> 
>> which will fail if no put is active, or wait for put completion otherwise.
>> Timeouts can be handled using the normal delay() mechanism. There would
>> probably also need to be a pvPutActive( var ) enquiry function.
>> 
>> I can't make any statement about when this might get done (assuming that
>> no-one gets there before I do). I would prefer to make this change only to
>> the still-unleased version that has the PV queueing facilities. We have been
>> using this operationally for several years.

In reply, Steve Lewis wrote:
>1) I agree you should combine this with your PV-queue capable version.
>
>2) Above calling sequences are OK, however, I think I prefer
>	pvPut( var )
>	pvPutCallback( var, wait, timeout )
>	pvPutDone( var )
>	
>  a) I prefer to stick with a fixed number of arguments for given calling name
>  rather than C++-style "different args is different semantics".

OK.

>  b) I think timeout should be specified--what would a "good" values
>  be for timeout?

See my comment to (c).

>  c) presumably if you choose wait==FALSE and later call pvPutDone(), when
>  the original timeout expires it also fails, but with E_TIMED_OUT
>  instead of E_NOT_WAITING.  And if it has succeeded already it returns
>  OK, just as it does for normal unblocking?

I'm not sure about this. If you aren't going to wait then can't you handle
timeouts directly via delay() and isn't this clearer than using a timeout
from some other call somewhere else in the code? If so, then I think it
should be OK to omit the timeout when "wait == FALSE" (but by all means
via a call with a different name).

Ned Arnold wrote:
>Here is something Marty and I put together one morning to provide put
>completion with SNL 1.9. After getting it working, my "unpredictable
>device" works like a charm. "put completion" solves many problems !
>Although the attached code is not "ready for release", it might help you 
>get started  :)
>
>string  sendString;
>assign  sendString to "LR:SCOPE1:sendCmdSO";
>
>int     sendStringId;
>
>calling statement in SNL ...
>
>                sendStringId = pvIndex(sendString);
>                .
>                .
>                .
>
>                sprintf(sendString, ":MEASURE:SOURCE CHAN1");
>%%              putAndWait(ssId, sendStringId, DBR_STRING, sendString);

This looks great for the "wait == TRUE" case.

I'm now wondering whether...

(a) support for getCallback _would_ be definitely desireable if this
    means that async errors during the get would be caught and reported
    via the callback (are they? Jeff?)

(b) putCallback should be integrated into SNL arrays rather like my
    queuing facilities are; this requires more thought, but it might be
    useful to be able to do a series of non-blocking putCallbacks to
    array elements and then have a single "done" call on the array which
    would wait for _all_ the puts to be complete

William

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System