Issue 15603: Multiprocessing creates incorrect pids

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 that can reproduce the issue.

Please let me know what more information I can provide.  

Thanks!

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 the R-Python bindings, rather than a bug in multiprocessing.

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 try/except to __get_valid_triplets.  Will report back.

> 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 (here begins the wild speculation on my part :-)), fork in the 
background so as to run the R engine in a separate process, the 
CPU-consuming processes would not be those directly created by 
multiprocessing.

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.

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, actually)"  ;-)

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.