🚀 go-pugleaf

In article <2985@brchh104.bnr.ca> news@brchh104.bnr.ca (news) writes:
>Netwise's current products support multithreaded applications (with
>the restriction that each connection be accessed within a single
>thread). What does NCS2.0 do in environments that don't support
>multiple threads? 

Maintaining a thread to connection mapping is a major restriction, one
which I would prefer not to program around.  Not only is it really
non-portable, but it is really non-portable in a way which seriously
constrains the architecture of my application.

NCS2.0 is part of the DCE.  An additional part of the DCE is the CMA
threads package.  The CMA threads package is just a user space
implementation of POSIX 1003.4b draft 4 threads (pthreads).  For
environments which have native pthreads, such as OSF/1, you just use
native pthreads.  For environments without native threads, you use CMA.

The supposed strength of the DCE is the integration of the parts; it is
unlikely that anyone would use NCS 2.0 RPC without the other DCE parts.

I seriously consider native threads to be more of a boon to distributed
applications writers than RPCs.  Hopefully over time, most environments
will have POSIX threads, so this *major* advantage of the DCE over Netwise
will go away...

By the way, HP employees being ignorant of what the automounter and amd
are is sooo symptomatic of their failings in the areas of distributed
computing.  The HP lack of tools for a distributed environment gives one
the sense that they really don't use a distributed heterogenous
environment in house.  They don't even have an automounter in their next
release and it took them till 1990 to get rdump!  Also, rewriting a
working application which uses Sun RPC to use NCS RPC is a stupid idea.
There really isn't much difference between the two.

regards,
fletcher
Fletcher Kittredge
BBN Software Products
150 CambridgePark Dr,  Cambridge, MA. 02140
617-873-3465  /  fkittred@bbn.com  /  fkittred@das.harvard.edu