Hi Holger, I am not saying there is anything wrong with the way xdist is handling a node going down at this point. the -n 1 was just my attempt to see if the timeout plugin would behave differently when running the test out of process.
I think it did, as pytest did not exit the way it does without xdist ... it just ran out of nodes this time and could not carry forward. > Coming to think of it, the xdist plugin might also do "timeout" handling > and send a keyboard interrupt from the outside to a running node. I think this is a good way of handling this. As Floris pointed out, there is always a danger of using signal (right now his marker allows to switch modes on a per test basis which is a good thing). > I am interested in OpenStack but you can you detail a bit more of what > you want to achieve? I will start a separate thread - OpenStack (as it is somewhat unrelated to the timeout subject). /Laurent -----Original Message----- From: holger krekel [mailto:hol...@merlinux.eu] Sent: Mon 3/19/2012 11:10 PM To: Brack, Laurent P. Cc: Floris Bruynooghe; holger krekel; py-dev@codespeak.net; Brard, Valentin Subject: Re: [py-dev] pytest-timeout 0.2 Hi Laurent, Floris, On Mon, Mar 19, 2012 at 16:47 -0700, Brack, Laurent P. wrote: > I don't want to make this issue overly complicated but here are some > scenarios (that we have). proper termination and handling of hanging tests is involved. So discussion and hearing use cases makes sense to me. > Our tests, in some instances, interact with python extensions written in C or > C++ (or in some case COM inproc server - yuk) which can be multi-threaded. > > If the hang occurs in a critical section in the C/C++ domain I am not sure > what the timeout effect would be but > Assuming that the test is pre-empted in a critical section (of the > extension), we would most likely be doomed anyway (mutexes would not be > released). Next test would hang, be aborted and so on. > > In our case, the safest thing to do is to run with xdist -n 1 so then the OS > takes care of doing most if not all the cleanup. > I am not so intimate with xdist but I was hoping that upon detecting that the > "remote process" had died, > xdist would restart a new one. It's reasonable to expect this from the xdist plugin, even when you run with "-n N" with N>1. > In this case pytest ended with: > > [gw0] win32 -- Python 2.7.2 C:\Python27\python.exe > Slave 'gw0' crashed while running > 'src/timeout/test_sample.py::TestTimeOut::()::test_hang' > > Which signaled the end of everything (other tests were not run). This is a > something we will have to solve internally > (and when we have the solution will be more than happy to contribute it > back). We might be able to restart a remote > Process on pytest_testnodedown(). We would be however too late to run any > restore() and chances are that those might hang as well. Indeed, no attempt is made to restart a node properly. It remains offline and when run with "-n1" everything dies because no node is left to continue. Not sure how hard it is to try to fix it. > More food for thoughts than anything at this point. > > Floris, thanks for your work. We are not yet in a position where we can help > much but we will get to it. Coming to think of it, the xdist plugin might also do "timeout" handling and send a keyboard interrupt from the outside to a running node. > /Laurent > > P.S.: Speaking of xdist, further down the road we are interested in extending > xdist (via its hooks) to interface it with OpenStack (dynamic provisioning of > VM). Anyone has any use for this or thinking about the same thing? I am interested in OpenStack but you can you detail a bit more of what you want to achieve? best, holger > > -----Original Message----- > From: floris.bruynoo...@gmail.com [mailto:floris.bruynoo...@gmail.com] On > Behalf Of Floris Bruynooghe > Sent: Monday, March 19, 2012 3:21 PM > To: Brack, Laurent P. > Cc: holger krekel; py-dev@codespeak.net; Brard, Valentin > Subject: Re: [py-dev] pytest-timeout 0.2 > > On 19 March 2012 16:38, Brack, Laurent P. <lpb...@dolby.com> wrote: > > It would also be nice to have a consistent behavior between sigalarm > > on/off. For instance, on Windows, pytest exits on first hang as opposed to > > *nix where the test is pre-empted and pytest moves on to the next one. > > I was writing up a response saying I didn't know how to do so, but while > doing so I thought it might be possible to emulate sigalrm with a timer > thread which fires an other signal. I might investigate the feasibility of > such an approach. I do worry about gratuitously using signals however, the > simple timer thread with os._exit() may always have to stay as the fail-safe > option. > > If anyone has any other ideas about this please let me know. > > Regards, > Floris > > > -- > Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | > www.kernel.org
_______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
