EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  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  <19951996  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: CA on VMS
From: [email protected] (Jeff Hill)
Date: Mon, 13 Feb 95 13:53:30 MST
> 
> Has 3.12 CA stopped being asynchronous on VMS or am I being dumb?
> 
> I am playing around with my first VMS CA client and I understood that
> CA used AST's to handle events. That is, my understanding is that event
> handlers would execute in AST context and so a call to ca_pend_event
> was not required for an event to be processed.
> 
> However, my event handlers only appear to be executed when I call
> ca_pend_event, or some other CA routine.
> 
> I don't mind if the functionality has changed, only I wish the
> documentation would be a bit more clear.

You are correct. I dropped AST driven CA event preemption under VMS 
because the MULTINET socket library isnt reentrant and they (TGV) 
dont appear to be interested in solving the problem. I was able to 
work around  these problems in the past however it was becoming 
increasingly difficult to remain portable.

You are also correct about the documentation needing to be updated
concerning this particular point. I have updated my copy and will
place this on the WEB prior to official release of R3.12.

> 
> An alternative question is - is there a way of a particular event
> forcing ca_pend_event to return? The way I see it, it always waits at
> least for the specified interval.
> 

You need a version of ca_pend_event () that returns immediately
if any CA events are executed? We accomplish this under UNIX by
using the routines in libCom/fdmgr.c (prototypes and minimal
doc in include/fdmgr.h). Basically, we wait in the file descriptor
manager until there is activity on one of CA's file descriptors 
and then call ca_pend_event(0.00001). The file descriptor manager 
always returns immediately after handling file descriptor activity
(even if the specified delay hasnt expired). I can point you
to several short example codes if you are interested.

The file descriptor manager is implemented on top of select().
The primary purpose of the file descriptor manager is to allow
multiple libraries that use file descriptors to co-exist within
the same process. Unfortunately, the MULTINET version of select
does not work with VMS channels that are not MULTINET sockets.
This may not be the case with UCX.

It also might be possible to add a new type of ca_pend_XXXX() to the
CA API.


Jeff
______________________________________________________________________
Jeffrey O. Hill			Internet	[email protected]
LANL MS H820			Voice		505 665 1831
Los Alamos, NM 87545 USA 	FAX		505 665 5107

Navigate by Date:
Prev: CA on VMS Nick Rees
Next: Re: Making releases Ian Smith
Index: 1994  <19951996  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: CA on VMS Nick Rees
Next: ASCII database formats (was Re: EPICS on the Alpha) winans
Index: 1994  <19951996  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·