It turns out that generic IPC on Windows using the Win32 APIs is not so
straightforward as it looks at first. In particular, you can't read/write
on a socket (must send/recv) and you can't send/recv on a pipe descriptor.
Nor can one select on a pipe file descriptor. These are major problems in
porting libpcp, because the low-level PDU routines have to manipulate PDUs
on either type of file descriptor, and at many points have no knowledge of
whether working with a socket or a pipe.
Using some other Win32 APIs (ReadFile/WriteFile) would work, but these
take a HANDLE, which is a pointer - and we really want to use an int, as
many of the impl.h libpcp routines are coded that way (would have to make
a number of ABI changes to go that route).
After several iterations, the following patch implements what seems like
the least terrible approach, and most importantly it does not perturbe the
PMAPI or the impl.h routines in libpcp either. The approach taken here is
to associate a socket true/false boolean state with each file descriptor,
using the global fd table that was added for PCP 1.0 <-> 2.0 versioning.
Whenever we add a socket descriptor we set the flag too, then the PDU code
can later tell whether its working with sockets or pipes when it needs to.
To make this easier, the existing __pmCreateSocket API is now used in most
places that create sockets, and a __pmCloseSocket interface is added to
do the platform-specific socket teardown.
With this change we now have a Win32 PCP library supporting communication
on pipes and sockets (daemon PMDAs) and socket based PMAPI clients. Yay!
It turns out that generic IPC on Windows using the Win32 APIs is not so
straightforward as it looks at first. In particular, you can't read/write
on a socket (must send/recv) and you can't send/recv on a pipe descriptor.
Nor can one select on a pipe file descriptor. These are major problems in
porting libpcp, because the low-level PDU routines have to manipulate PDUs
on either type of file descriptor, and at many points have no knowledge of
whether working with a socket or a pipe.
Using some other Win32 APIs (ReadFile/WriteFile) would work, but these
take a HANDLE, which is a pointer - and we really want to use an int, as
many of the impl.h libpcp routines are coded that way (would have to make
a number of ABI changes to go that route).
After several iterations, the following patch implements what seems like
the least terrible approach, and most importantly it does not perturbe the
PMAPI or the impl.h routines in libpcp either. The approach taken here is
to associate a socket true/false boolean state with each file descriptor,
using the global fd table that was added for PCP 1.0 <-> 2.0 versioning.
Whenever we add a socket descriptor we set the flag too, then the PDU code
can later tell whether its working with sockets or pipes when it needs to.
To make this easier, the existing __pmCreateSocket API is now used in most
places that create sockets, and a __pmCloseSocket interface is added to
do the platform-specific socket teardown.
With this change we now have a Win32 PCP library supporting communication
on pipes and sockets (daemon PMDAs) and socket based PMAPI clients. Yay!