> 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
[email protected]
--------------------------------------------------------------------------------
- Navigate by Date:
- Prev:
correction! Michael Borland
- Next:
CSO tickets at ICALEPCS Martin J. Knott
- Index:
1994
<1995>
1996
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:
Re: ca_pend_event question (VAX/VMS only) 415
- Next:
BURT available on Alpha/Unix platform, but a few problems 415
- Index:
1994
<1995>
1996
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
|