JP

Any update to this issue? I would love to see a fix soon as this issue is plaguing me. Google Code Info: Author: [email protected] Created On: 2010-12-22T22:50:58.000Z

I don't have time to work on nose myself right now, but would happily accept a patch (with tests) that fixes this issue. Google Code Info: Author: [email protected] Created On:...

I wish I had the knowledge to fix it myself. Google Code Info: Author: [email protected] Created On: 2010-12-27T18:59:50.000Z

I was able to do a quick fix using multiprocessing.Queue and multiprocessing.Array to manage passing data across the processes. Because the multiprocess plugin also uses the python multiprocessing module, this...

I'm attaching a new version of xunitmultiprocess.py that accurately measures the timings. rosen diankov, Google Code Info: Author: [email protected] Created On: 2011-02-23T12:02:42.000Z

Google Code Info: Author: [email protected] Created On: 2011-02-23T13:21:05.000Z

I'm attaching a new version of xunitmultiprocess After doing a little more testing, it became clear that multiprocessing.Manager is a better alternative than multiprocessing.Queue since it doesn't block on exiting...

Please get the latest xunitmultiprocess.py from: https://openrave.svn.sourceforge.net/svnroot/openrave/trunk/test/noseplugins/xunitmultiprocess.py In order to use it with the new multiprocess.py, have to do: multiprocess._instantiate_plugins = [xunitmultiprocess.Xunitmp] Google Code Info: Author: [email protected] Created On: 2011-03-25T05:51:09.000Z

Rosen: I'm glad to see you're using Manager.Queue rather than the raw Queue. It's troubling to see coupling between the multiprocess and xunit plugins. They shouldn't _need_ to be aware...

does the new multiprocess code already address this issue? Some (maybe all) of the patches here have been applied already in Issue 399 Google Code Info: Author: kumar.mcmillan Created On:...