Doug wrote:

<< snip >>

>What is interesting is the approach that the HP development engineers are
taking:
>
>They are seriously discussing removing pthread from FOS and moving it to
NS.
>
>That is certainly one way to solve the problem!
>
>It may be well to consider petitioning HP through Interex to leave the
POSIX
pthread function in FOS and moving the resolution
>of the problem from NS to FOS.
>

As one of the HP engineers mentioned above I thought I'd respond that we
have no plans to move pthreads to NS. I have not heard that one before!
In fact, my colleagues in CSY Bangalore are working quite hard to update
the current pthreads code so that it is closer to draft 10 compliance. The
current code is draft 4 based for those familiar with this.

Technically, at the present time, Posix pthreads are not part of FOS. It was
written to support OSF/DCE RPC. Right now we do not support writing
threaded applications outside of RPC. We are working towards allowing
that we're just not quite there. We will be soon.

As for there being some requirement that NS be installed, quite frankly that
is
a new one by me. When "tm_cms_type_mgr" is bound to STDIN/LIST Posix
apps (not necessarily threaded apps) may not work quite correctly. This is
because Posix may make calls like IOCTL() that tm_cms_type_mgr can't
handle. The only way I know of that you get this type manager bound is
when the device sub-type is a zero. For subtypes 1, 2 or 3 we bind
tm_terminal. That one works. I have never seen any code that specifically
looks for nor requires NS be available. I could be wrong, wouldn't be the
first time but I've never heard of NS being required.

And finally, for anyone planning to attend HPWorld in September I will be
presenting a tutorial on Posix pthreads and MPE/iX. We want people to
begin prototyping things with threads as we work on getting things ready
for prime time (which will be soon!).

Hope this helps!

Bill Cadier
Hewlett-Packard
Commercial Systems Division