Chris added the comment:
Ugh, a server reboot seems to have cleared this all up (FML). It's been
running well past the point of previous failure. I suppose I'll never know why
it was failing. I'm going to close this out. Thanks for your time in helping
me think this through.
--
re
Chris added the comment:
Also, when I said "...that tracebacks will now flow up to the main process from
the worker processes (which makes perfect sense, actually)", I meant to say
"...that tracebacks will NOT flow up to the main process from the worker
processes (which makes perfect sense, ac
Chris added the comment:
Using top/'ps aux' is not the issue. I have code running now with the
try/except. Will report back ASAP. I suspect that you're correct about
something in the R pipeline failing. Hopefully, I'll get a good traceback.
--
_
Antoine Pitrou added the comment:
> Chris added the comment:
>
> That they don't appear in top. I was using that as a proxy for existence.
Well, I don't know in which way you use "top", but by default it will
only show you the N most CPU-consuming processes. If the R bindings, for
example (he
Chris added the comment:
That they don't appear in top. I was using that as a proxy for existence. I
wrote a test case without R and realized (accidentally) that tracebacks will
now flow up to the main process from the worker processes (which makes perfect
sense, actually). I added explicit
Antoine Pitrou added the comment:
Your report is rather ambiguous. Do you claim that said pids don't exist, or
that they don't appear in "top"?
Also, do you manage to reproduce without R, or do you need to use R to
reproduce? I would suspect an issue (or a misunderstanding on your part) with
New submission from Chris:
http://stackoverflow.com/questions/11884864/python-multiprocessing-creates-incorrect-pids
Jesse Noller suggested that I submit this stack overflow as a bug so it can be
examined. As the problem is kind of domain specific, it's not easy to come up
with a test case th
