|
| Hi all,
I have a somewhat unusual question (keep in mind, it's been a while
since I did any Unix programming): is there a way to find out when a
process on the other end of the pipe/FIFO/PTY has blocked waiting for input?
To give you a bit more background, I have a customer-supplied library
(an .so), which my process hosts. The library is a black box, and the
customer is adamant about not releasing the source code. What they want
is for my process (a daemon) to relay all output of the library to their
process, which is connected to mine via a socket. They also want (and
this is the hard part) to be notified when the library blocks in a read
call on stdin so they can send it some data. They are unable to supply
any input to the program unless they are prompted, so this is not like
telnet where you can send input at any time and simply buffer it in the
PTY queue.
Here is what I tried so far:
- created a PTY and dup'ed the slave file descriptors to stdin, stdout
and stderr
- started a pthread, which blocks in a poll() on the PTY master, watches
for I/O events and relays the output to the customer's socket
Of course, this works just fine for output as this is what telnetd does.
However, due to internal buffering in the PTY, the master descriptor
always reads as ready for input even if the slave descriptor is not
being read. This part makes sense to me, because of the buffering
involved. I expected the same to occur with pipes, FIFOs and
socketpairs, which I confirmed to be true experimentally. So, the
question remains - is there an alternate way to tell when a read call is
issud on a PTY slave descriptor, or the other end of the pipe?
Another requirement is that the program be portable to Linux, AIX 4.3
and 5+, HPUX and Win32. I was able to get around the problem on Win32 by
using anonymous pipes and WaitForSingleObject. Windows returns a timeout
on the wait call for a particular file descriptor if it is being
actively read, but is there a similar feature in Unixes?
TIA,
Axle
|
|