I used os.waitpid,but I still can't Zombie process?

[lokie.spods]

"Donn Cave" <donn at drizzle.com> wrote in message
news:1009167768.180019 at yabetcha.drizzle.com...
> Quoth "lokie.spods" <lokie.spods at ntlworld.com>:
> | "Donn Cave" <donn at drizzle.com> wrote in message
> | news:1008825134.967004 at yabetcha.sttl.drizzle.com...
> ....
> |> Hm, I think we're going in circles here - if I remember right, he was
> |> having problems with EINTR because of SIGCHLDs.  Between that and the
> |> extra problems Python has with signal handling, I personally think
SIGCHLD
> |> is a total loser for Python programs.
>
> | As all child processes will raise SIGCHLD upon exit it seems stupid to
> | ignore the oppertunity to take advantage of the signal and perform
cleanup
> | as its required, working smarter not harder. Now your point mentions
EINTR,
> | regardless of whether you write code to handle that signal, or leave it
> | unhandled some routines are going to exit anyway with EINTR. Re-reading
the
> | OP's code snippet, it looks like any IO that could exit with EINTR is in
the
> | child and out of scope of that signal anyway.
>
> SIGCHLD will abort your I/O functions with EINTR _only_ if you establish
> a SIGCHLD handler.  It's a last resort.
>
Which assumes that the calling process left SIGCHLD in its default state.
You can't make that assumption, for example I know of one shell that defines
a handler for SIGCHLD which then gets inherited by any subsequent processes.
Hence after the Christmas cheer has worn off I'll write a few example
programs to see if the Python interpreter overrides the sigaction with an
ignore setting.

> | I read your idea of signalling process completion back to the calling
> | process via a pipe with interest. It fits in with an idea I'm playing
with
> | for a threaded DNS server, the idea being that a thread signals the main
> | process to awake and deal with the results, so the main process can
> | blissfully sleep in a select call until needed. As said server is in C
not
> | Python, it'll probably be very offtopic to report on success or failure
of
> | that approach, but intuitively I expect it to work as advertised.
>
> Sure, but it's rather different than what I was talking about there.
> I don't expect the child process to actually write anything to the pipe
> or be aware in any way of its existence.  Its sole purpose is to generate
> end of file when the child exits.  Would be reliable only if certain
> details are worked out, though.
>
> Donn Cave, donn at drizzle.com
Taking OP's code snippet, I assume your idea would work something like this
(off the top of my head, so excuse mistakes).....

exc_items = []
while 1:
  ...
  new_item = os.pipe()
  ret=os.fork()
  if ret==0:
     os.close(new_item[0])
     HOST=udpaddr
     PORT=21567
     ADDR=(HOST,PORT)
     udpSerSock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
     udpSerSock.sendto(data,ADDR)
     udpSerSock.close()
     break
  os.close(new_item[1])
  exc_items.append(new_item[0])
  big_item = select.select([], [], exc_items, 0)
  for cl_items in big_item[2]:
    os.close(cl_items)
    os.waitpid(-1,os.WNOHANG);
    exc_items.remove(cl_items)

Taking the same code and applying my idea would result in something rather
like this (also off the top of my head, so excuse mistakes).

read_items = []
end_sig = os.pipe()
read_items.append(end_sig[0])
while 1:
  ...
  ret=os.fork()
  if ret==0:
     HOST=udpaddr
     PORT=21567
     ADDR=(HOST,PORT)
     udpSerSock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
     udpSerSock.sendto(data,ADDR)
     udpSerSock.close()
     os.write(end_sig[1], "\n")
     break
  big_item = select.select(read_items, [], [], 0)
  for e_items in big_item[0]:
    if e_items == end_sig[0]:
      discard = os.read(end_sig[0], 1)
      os.waitpid(-1,os.WNOHANG);

I leave it as an example to the reader, to check how many characters are
ready to be read from the FD and loop calling waitpid appropriately :-)'s

Anthony McDonald
--
Spammer's please note, all spam sent to this address immediately raises a
complaint with your network administrator.