3

I've starting using socketpairs on linux and windows in order to capture the output of subprocesses on both platforms. I do this by copying STD* onto one of the sockets in the socketpair (I'm using Win32::SocketPair in perl for socketpair's on windows). The main reason I am doing this is so that read do NOT block on the output file handles.

The problem I have is that kill(0,...) doesnt work on windows, so I need another way to detect the process as down. I looked into SO_KEEPALIVE, but that doesn't seem to work on socketpairs... I used setsockopt(...) then getsockopt(...) and the SO_KEEPALIVE option was off before and after the call to setsockopt().

Then I started looking into polling for events on the socket. The POLLHUP event looked promising, but I'm not sure it works when they're used like this.

I'm looking to automate interactive programs (no, I can't use Except as it doesn't work on windows platforms... unless you found one that does?). I've been testing with "cat" on windows (I have cat.exe installed). It has looked good so far, but there are 2 issues:

  • can't detect if process just dies (kill(0,...) doesnt work)
  • can't detect EOF from subprocess (sysread seems to always return undef or bytes read, never 0, even after I shutdown($sock, 1))

I may be doing something extremely dumb, but any advice/help would be appreciated.

UPDATE: I started using waitpid($pid, WNOHANG) to detect the "still running" condition which helps as it seems the process always dies after everything has been read. waitpid returns 0 if the pid is still running. However, it's not an EOF, its better than nothing, but I'm still looking for other input. This obviously isn't ideal.

UPDATE2: This Q/A helped with the EOF part of my question, not perfect, but better: How epoll detect clientside close in Python?

Community
  • 1
  • 1
dlamotte
  • 6,145
  • 4
  • 31
  • 40
  • In general, a socket can't tell when the other end of the connection has dropped. That's just the nature of TCP. Network applications implement heartbeats and close connection conventions for this reason. – mob Dec 15 '09 at 16:43
  • I guess I thought thats what KEEPALIVE's are for, am I mistaken? – dlamotte Dec 15 '09 at 17:15
  • KEEPALIVE is to tell the server to try to keep the connection open, but the server might not want to or be able to respect it. Often with KEEPALIVE, there is a convention to include the message length with the message (like the "Content-length" header with HTTP/1.1) so the receiver knows exactly how many bytes to read. – mob Dec 15 '09 at 17:58

2 Answers2

1

If it's supported in the WIN32 environment, and your process is spawning the child processes, you could try setting up a signal handler to catch a SIGCHLD signal from the spawned processes in the parent process... something like:

$SIG{CHLD} = sub { print "caught sigchld from child process"; };

That should tell you if one of the subprocesses exited.

Aquatoad
  • 778
  • 8
  • 21
  • ... I'm pretty sure signals in general are a "unix-ism". Unless I'm missing something... I don't think this would work on the windows platform. But I spose I can try it... – dlamotte Dec 15 '09 at 16:17
  • Yes, that's true, signals are a UNIX thing. The question would be whether Win32 Perl uses Windows' ITC implementation and emulates them via the API (i.e. the signaling interface in Perl) or whether they provide a completely separate API to hook into messaging. – Aquatoad Dec 15 '09 at 17:00
  • 1
    And the answer would be no (unless you're using Cygwin). – mob Dec 16 '09 at 00:22
0

In Linux, you can set a socket to be non-blocking (since at least 5.8):

 $socket->blocking(0);   # or (*SOCKET)->blocking(0);

That doesn't work on Windows (well, maybe it does in 5.10), but you can use the 4-arg select call to see if there is input on a socket before you attempt to read it (and in Windows, 4-arg select only works on sockethandles, not on filehandles or pipes).

If you still need to tell whether a Windows process (with a known PID) is active, checkout the Win32::Process::Open method, which will try to open a handle to a windows process and return zero on failure.

EDIT: I didn't notice before that you said the sockets come from subprocesses. In that case, you can just call

waitpid $pid, WNOHANG;   # and    use POSIX ':sys_wait_h'

at any time. When waitpid doesn't return -1, you know the process is dead.

mob
  • 117,087
  • 18
  • 149
  • 283
  • I'm using select() to check for pending input, but the meat of my question is about how to detect if the connection is still alive. I also use non-blocking I/O even though it doesn't work well in windows... if at all. I'll look into the Win32::Process::Open method. – dlamotte Dec 15 '09 at 16:16
  • I'm pretty sure our brains are linked... I JUST implemented this... without looking at your edit first... and it just popped into my brain. hah! – dlamotte Dec 15 '09 at 16:44
  • Yeah, I've been thinking about fork/socket stuff a lot lately, too. – mob Dec 15 '09 at 17:53