* Original Area: comp.os.os2.programmer.misc
* Original To  : Robert J. Fenney

I am using LOCAL named pipes, not named pipes across a network.  So far I
have been able to reliably reproduce three problems using small to medium
size test cases on two separate computers.  One of the computers is a
Micronics 486DX/50 EISA system with 32MB RAM, the other is an Austin
486DX2/66 notebook system with 16MB RAM.  At this point,I am using OS/2 3.0
on both systems.

The three problems I have been able to reproduce are:

1) Terminating a named pipe server program prior to all clients
   detaching results in the entire system crashing with a TRAP D.

   I first reported this problem on OS/2 2.x (all versions), probably
   around May 1994.  It was given APAR PJ14747 and I got a fix around
   August.  The fix didn't make it into the OS/2 3.0 kernel.

   The new problem report on OS/2 3.0 is PMR 0x807,PSY.


2) DosConnectNPipe() is not reliable -- sometimes it will not
   unblock when DosOpen() is called to establish a connection.
   This appears to be a race condition as it seldom fails on
   very slow computers and often fails on fast ones.

   I first reported this problem on OS/2 2.1 around October or
   November 1993.  It took a very long time to get anybody to
   even read the source code I supplied for a test case.
   I say this because the responses I repeatedly got back from
   IBM indicated that the several people who had looked at the
   problem either hadn't a clue about OS/2 programming or more
   likely didn't bother to look at the source code carefully
   and perhaps run it under a debugger.

   It took well over half a year to get them to issue an APAR.  It was
   finally given APAR PJ14975.  I received an improved kernel around
   September.  It wasn't quite what I wanted, but was acceptable.
   This fix didn't make it into OS/2 3.0, either.

   The new problem report on OS/2 3.0 is PMR 0x818,PSY.


3) Client to server messages writes of longer than about 4196 bytes
   (the exact cutoff seems to vary a few bytes) are fragmented into
   two sections.  For example, if the client writes a message that is
   4600 bytes long, the server side might get back 180 bytes
   of a message from the first DosRead() call and the remaining 4420
   bytes of the message in the second DosRead() call.
   DosQueryNPipeInfo() indicates the pipe is in message write mode,
   message read mode, and has buffers large enough to completely
   contain the messages involved.

   I plan to simplify this test case a bit more so I don't have to
   send so much code, but using IPMD I can watch the DosWrite()
   call being made and the corresponding unblocking of the DosRead()
   on the server side an instant later.  Based on the values of the
   parameters and return variables, the DosWrite() reports it wrote
   all the bytes without a problem, but the DosRead() only returns
   part of the message.  Thus I don't see how this could be a problem
   with my program as between the DosWrite() and the DosRead() it
   does nothing -- the code being run is in the operating system.



In addition, I am working on determining if two more problems are due to my
code or OS/2 defects:

4) Server to client message writes start disappearing.  In other
   words, the messages are lost.  No error code is returned (i.e.,
   the DosWrite() returns NO_ERROR),  Other times the data in
   the messages is trashed -- for example, I can see spikes in the
   data when it is graphed that are not in the original data.

   What really makes me suspect this is an OS/2 problem is that
   once this message corruption and loss has started, I can
   terminate all of the processes involved and restart them
   and the problem appears again immediately.  These same
   processes had worked for minutes or longer immediately after a
   reboot with no apparent trouble.  And the only way to get
   them to work again once the trouble starts is to reboot the
   computer.  The messages involved are typically between about 5000
   and 30000 bytes long, but the message buffers are big enough to
   completely hold messages much larger than those lengths.


5) When I was working on a test case for problem #3, I ran into
   a situation where the test case process (which had both
   client and server threads in the same process to simplify
   running the test case) would deadlock the session -- the
   process would get stuck and could not be terminated with
   any utility I tried.  This may be a more general problem
   in that OS/2 has never been very good in my experience about
   killing processes that have blocked threads.


Once again, these problems are all occuring in local named pipes, not
network named pipes.  The plan for this software is that eventually
(probably in mid-1995) we will start working on a distributed version. We
used named pipes versus some other IPC mechanism because at the time this
decision was made (near the end of 1992) there wasn't any other network
capable OS/2 IPC mechanism that was also built into OS/2 in a local
version.  At this point,it looks like perhaps TCP/IP or DSOM would also
work.  But I really don't want to have to rewrite code that was working
well and hadn't been changed in months.  Thus I'm very nervous and anxious
about all the troubles I am having with named pipes.

If it turns out that some of these problems are my own mistakes, I will
readily admit that.  But at the moment, at least for the first three
problems I mention, the many hours of experimenting I have done don't
indicate the problem is in my source code aside from the general point that
I wouldn't be having these problems if I wasn't using named pipes. 
Obviously, that's like an insurance company partially blaming you for an
accident "because you were there" -- i.e., if you hadn't been
driving on X Street at 11:02PM, the Mr. Z wouldn't have plowed through the
stop sign and smashed into your car.


--- Maximus/2 2.01wb