Re: ca_pend_event question (VAX/VMS only)

[hill@luke.atdiv.lanl.gov (Jeff Hill)]

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

I saw that also. Perhaps this is a way to deal with DEC CC's obnoxious 
involuntary replacement of recv with decc$recv. @#$%$!

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

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

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

Jeff

______________________________________________________________________
Jeffrey O. Hill			Internet	johill@lanl.gov
LANL MS H820			Voice		505 665 1831
Los Alamos, NM 87545 USA 	FAX		505 665 5107