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  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 
<== Date ==> <== Thread ==>

Subject: Re: ca_pend_event question (VAX/VMS only)
From: Tony Cox - (415)926-3105 <tcox@ssrl01.slac.stanford.edu>
To: hill@luke.atdiv.lanl.gov
Cc: tech-talk@epics.aps.anl.gov
Date: Wed, 09 Aug 1995 10:10:22 PST
Jeff writes:-
>
>Under UNIX many applications get around the need to poll by waiting 
>in select() ala "fdmgr.c". Unfortunately, this is not an option under VMS.
>If I had more time I would look again at an AST driven version for VMS. 
>The problem with this so far is trusting that there will be a standard 
>interface to QIO maintained between VMS TCP/IP venders.

Multinet (the preferred VMS TCP/IP) also provides a stub driver which emulates
the DEC supplied UCX driver interface, so this is a possible route (but see
below). Unfortunately, TGV have to play `catchup' sometimes with VMS developers
who sometimes do not document extensions to the UCX driver interface - 
for example, Mosaic didn't function with Multinet 3.2 until TGV found out what
changes DEC made to UCX and subsequently released a patch. This is unlikely
to be an issue for applications which just read and write through sockets,
however, since the recent changes have only been tweaking interfaces to lower
level protocol accessed through sockets.

>
>Another possibility is to use the thread library now available under VMS.
>The CA client library could easily be modified to be thread safe in a VMS 
>environment (it is already under vxWorks). Unfortunately, the MULTINET 
>socket library isnt thread safe. 

The problem with VMS at present is not so much that the Multinet library isn't
thread safe, but that the VMS thread implementation is user mode rather than
kernel mode. One consequence of this is that send/recv block the whole process,
rather than the individual thread.

I've developed code which solves this (for another project). I have jacket
send/recv routines which are functionally equivalent to the Multinet ones,
but actually block on condition variables which are then signalled by the
QIO completion AST. Voila! Thread safe Multinet (equivalent) routines.
email me if you want further information on this.

In general, however, I think it would be bad practice to allow the VMS channel
access routines to diverge (again) from the facilities available under Unix.
The goal should be to provide a consistent interface across all OS's, even if
this means a degree of `dumbing down'.

Tony
--------------------------------------------------------------------------------
Dr Anthony D Cox
Computer Systems Specialist
Stanford Synchrotron Radiation Laboratory
Stanford Linear Accelerator Center
MS 69, Box 4349
Stanford CA 94305
tcox@ssrl01.slac.stanford.edu
--------------------------------------------------------------------------------


Navigate by Date:
Prev: Re: ca_pend_event question (VAX/VMS only) Jeff Hill
Next: Re: BURT available on Alpha/Unix platform, but a few problems Michael Borland
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 
Navigate by Thread:
Prev: Re: ca_pend_event question (VAX/VMS only) Jeff Hill
Next: Re: ca_pend_event question (VAX/VMS only) 415
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 
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 ·