[Mailman-Developers] fork() problem and popen2.py test

[Harald Meland]

[Christian Tismer]

> The reason turned out to be dependent wether Python 1.5 (the early
> version, of course) was made with threads or not.
> The threaded version had a bad effect on sys.stdin after an
> os.fork(). sys.stdin was a "bad file number" in the child process.
> Maybe these are known things, but there are some issues:
[...]
> To the Mailmen:
> It was quite hard to track this error down through the
> mailman scripts. Finally, I ended up if I made the deliver
> fork temporarily into a do-nothing.
> The "deliver" script does a number of forks. I does no proper
> checking if the forks work (under Linux, btw., fork never returns
> ENOMEM, so the check isn't safe yet).

I don't understand -- "forker(tries)" in the "deliver" script tries
fork()ing, catches any exceptions raised, and re-raises them if a) the
error causing the exception weren't EAGAIN or b) this were failed
fork() number "tries"+1.

Catching the exception is about as far as you can go to "check if the
forks work", IMHO -- when fork() stops working, there usually aren't
very many clever things worth doing (short of giving up), are there?

> Deliverer.py also trusts the os.popen very much.

Well, os.popen() should bail out by raising os.error whenever it's
behaving "untrustworthy", shouldn't it?

> Anyway, sys.stdin is read without error checking in the deliver
> script. I think, some more checks are necessary to guarantee that
> failing deliveries get noticed.

I don't think I have understood enough of the problem to fix this
properly, so any suggestions on exactly _what_ those extra checks
should check for would be nice :)

-- 
Harald