CS> Recently I saw somebody asking questions on the 64KB
 CS> boundary problem with named pipes on OS/2 2.x and 3.0.

 CS> My personal opinion is that this is a mistake in
 CS> the 32-bit OS/2 API
 CS> that has persisted because named pipes code is still
 CS> 16-bit and thunking has to be done.

 PF> Being 16 bit (and I do not know if it actually is or
 PF> not) in itself will not cause this limitation ---

I've been told by IBM that it is.

 PF> there are plenty of 16bit code pieces in OS/2 that can
 PF> handle this "problem".

I agree that this could have been handled by having the 16-bit code deal
with 64KB boundary conditions so that 32-bit OS/2 apps would not have to
care about this.  Or the code could have been rewritten as 32-bit and a
16-bit wrapper been provided for 16-bit OS/2 apps to use.

Unfortunately, this isn't the only 64KB boundary problem that has been
exposed through the 32-bit OS/2 API. I had problems with 64KB boundaries
and the pCtlData parameter to WinCreateWindow() back in the days of OS/2
2.0.

 PF> The only problem is some dumb or lazy programmers at ibm.

That's also my thinking, but I've tried not to actually say that to them
while on the telephone -- telling somebody they or their coworkers are
stupid or lazy usually doesn't go over well in the long run.  I just hope
this foolishness goes away in the microkernel version of OS/2.

 CS> Anyway, that said, there do appear to be several ways
 CS> to deal with this problem.

 PF> My method is more simple -- I 'stage' every read/write in a static local
 PF> buffer (ie: avoid dynamic memory allocs,  which are

Do you have a seperate static buffer for every named pipe,
or is a single buffer shared?  How big do you make the buffer? If you're
using small messages (maybe up to a few thousand bytes),this solution seems
very reasonable. My code often needs to send back around a megabyte of data
in response to a request.

 PF> slow).  I stage every buffer; I don't want to waste

The 64KB boundary check is only a single line of C/C++ code -- basically it
just compares the top 16 bits of two addresses. Most of the time there is
no need for allocating a temporary buffer or for copying data.  And after I
dumped message mode completely, there is no need for dynamically allocating
temporary buffers or memcpy() any more -- I just segment up the read/write
calls into chunks that do not cross 64KB boundaries.  This also has the
advantage of getting rid of the 64KB message size limit.

 PF> time checking for the boundary,  and the memcpy() is
 PF> insignificant compared to the speed of a named pipe
 PF> (which are the slowest for of OS/2 IPC;  but are handy
 PF> when your client and server have the option of being
 PF> on different computers).

This is why I decided to use named pipes in the first place,even though
we're still not using the networking ability yet.

Distributing subsystems on networks is still a few months away,but by that
time we might even consider some other IPC mechanism such as TCP/IP or
DSOM.  I don't have any experience with DSOM yet,however -- do you know how
it compares in performance to named pipes for invoking remote services that
can cause a few hundred KB (or even a megabyte or two) of data to be sent
back as a response?


--- Maximus/2 2.02