Re: ca_pend_event question (VAX/VMS only)

[Tony Cox - (415)926-3105 <tcox@ssrl01.slac.stanford.edu>]

> tc writes:-
>>
>> 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). 
>
> Jeff writes:-
>
>I saw that also. Perhaps this is a way to deal with DEC CC's obnoxious 
>involuntary replacement of recv with decc$recv. @#$%$!

Not really. This is just VMS's way of isolating name spaces in shareable
libraries. It _used_ to be that DEC "C" was an anomaly in all the supported
languages. Shared library references had to be included explicitly in the
link step. With the ANSII C and C++, DEC regularized the link step. Both
compilers prepend "decc$" to some reserved library calls, and then the link
step scans (potentially) _all_ language specific shareable libraries to resolve
the symbols. What they are attempting to do is isolate decc$recv from for$recv
and pas$recv or whatever. You can avoid this behaviour in a number of ways.
The simplest is to use the switch "/PREFIX_LIBRARY_ENTRIES=(EXCEPT=recv)" with
the CXX compiler.

>
>> 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.
>
>Ouch. I wasnt aware of this limitation.

Rumoured to be going away in a subsequent release of VMS. Probably only for
Alpha/VMS, not VAX/VMS. Probably 6 months out.

>
>> 
>> 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.
>
>Does this include select?

No, 'fraid not. I've never been keen on `select', and it isn't necessary in
a properly designed threaded program. However, I've just checked the
documentation and it seems quite possible to implement. The only strangeness
is that you have to issue multiple $QIO's for each channel (fd) which you
are selecting.

>
>> 
>> 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'.
>> 
>
>Another possibility is to encapsulate the transport level calls so
>that the socket interface is only one of several OS dependent 
>communication API options.


Now _that_ is the best way.....

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
--------------------------------------------------------------------------------