Re: with timeout(...):

John Nagle <[EMAIL PROTECTED]> wrote: > Diez B. Roggisch wrote: > > Nick Craig-Wood wrote: > > > > > >>Did anyone write a contextmanager implementing a timeout for > >>python2.5? > >> > >>And have it work reliably and in a cross platform way! > > > > Cross platform isn't the issue here - reliab

Re: with timeout(...):

Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > "Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: > > > I'd like there to be something which works well enough for day to day > > use. Ie doesn't ever wreck the internals of python. It could have > > some caveats like "may not timeout during C functio

Re: with timeout(...):

Nick Craig-Wood schrieb: > Diez B. Roggisch <[EMAIL PROTECTED]> wrote: >>> I beleive the convention is when calling an OS function which might >>> block the global interpreter lock is dropped, thus allowing other >>> python bytecode to run. >> >> So what? That doesn't help you, as you are single-t

Re: with timeout(...):

"Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: > I'd like there to be something which works well enough for day to day > use. Ie doesn't ever wreck the internals of python. It could have > some caveats like "may not timeout during C functions which haven't > released the GIL" and that would still

Re: with timeout(...):

Diez B. Roggisch wrote: > Nick Craig-Wood wrote: > > >>Did anyone write a contextmanager implementing a timeout for >>python2.5? >> >>And have it work reliably and in a cross platform way! > > Cross platform isn't the issue here - reliability though is. To put it > simple: can't be done that way

Re: with timeout(...):

On Thu, 29 Mar 2007 11:30:04 -0500, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: >Diez B. Roggisch <[EMAIL PROTECTED]> wrote: >> > >> > I beleive the convention is when calling an OS function which might >> > block the global interpreter lock is dropped, thus allowing other >> > python bytecode to ru

Re: with timeout(...):

Diez B. Roggisch <[EMAIL PROTECTED]> wrote: > > > > I beleive the convention is when calling an OS function which might > > block the global interpreter lock is dropped, thus allowing other > > python bytecode to run. > > > So what? That doesn't help you, as you are single-threaded here. The >

Re: with timeout(...):

Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > "Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: > > > Well, yes there are different levels of potential reliability with > > different implementation strategies for each! > > Gadzooks! Foiled again by the horses for courses argument. > > ; - ) ;

Re: with timeout(...):

> > I beleive the convention is when calling an OS function which might > block the global interpreter lock is dropped, thus allowing other > python bytecode to run. So what? That doesn't help you, as you are single-threaded here. The released lock won't prevent the called C-code from taking as

Re: with timeout(...):

"Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: > Well, yes there are different levels of potential reliability with > different implementation strategies for each! Gadzooks! Foiled again by the horses for courses argument. ; - ) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list

Re: with timeout(...):

Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > "Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: > > Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > > > But would be useful to be able to do without messing with > > > threads and GUI and imports. > > > Could be hard to implement as the interpreter

Re: with timeout(...):

"Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: > Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > > > But would be useful to be able to do without messing with > > threads and GUI and imports. > > Could be hard to implement as the interpreter would have > > to be assured of getting control

Re: with timeout(...):

On Mar 27, 3:28 pm, Paul Rubin wrote: > Nick Craig-Wood <[EMAIL PROTECTED]> writes: > > It could be made to work I'm sure by getting the interpreter to check > > for timeouts every few hundred bytecodes (like it does for thread > > switching). > > Is there some reason not

Re: with timeout(...):

Nick Craig-Wood <[EMAIL PROTECTED]> writes: > It could be made to work I'm sure by getting the interpreter to check > for timeouts every few hundred bytecodes (like it does for thread > switching). Is there some reason not to use sigalarm for this? -- http://mail.python.org/mailman/listinfo/pytho

Re: with timeout(...):

Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > so Diez is probably right that the way to go is to put the timer in the > python interpreter loop, as its the only thing around that you could > more or less trust to run all the time. > > But then it will not read as nice as Nick's wish, but mo

Re: with timeout(...):

Klaas <[EMAIL PROTECTED]> wrote: > On Mar 26, 3:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > > Did anyone write a contextmanager implementing a timeout for > > python2.5? > > > > I'd love to be able to write something like > > > > with timeout(5.0) as exceeded: > > some_long_run

Re: with timeout(...):

"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > Nick Craig-Wood wrote: > > > Did anyone write a contextmanager implementing a timeout for > > python2.5? > > > > I'd love to be able to write something like > > > > with timeout(5.0) as exceeded: > > some_long_running_stuff() > >

Re: with timeout(...):

James Stroud <[EMAIL PROTECTED]> wrote: > Nick Craig-Wood wrote: > > Did anyone write a contextmanager implementing a timeout for > > python2.5? > > > > I'd love to be able to write something like > > > > with timeout(5.0) as exceeded: > > some_long_running_stuff() > > if exceede

Re: with timeout(...):

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Mar 26, 3:16 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > But to make that work reliably, it has to be ensured that no sideeffects > > occur while being in some_long_running_stuff. which doesn't only extend to > > python itself, but also e

Re: with timeout(...):

On Mar 26, 3:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > Did anyone write a contextmanager implementing a timeout for > python2.5? > > I'd love to be able to write something like > > with timeout(5.0) as exceeded: > some_long_running_stuff() > if exceeded: > print "O

Re: with timeout(...):

On Mar 26, 3:16 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > But to make that work reliably, it has to be ensured that no sideeffects > occur while being in some_long_running_stuff. which doesn't only extend to > python itself, but also external modules and systems (file writing, network > c

Re: with timeout(...):

Nick Craig-Wood wrote: > Did anyone write a contextmanager implementing a timeout for > python2.5? > > I'd love to be able to write something like > > with timeout(5.0) as exceeded: > some_long_running_stuff() > if exceeded: > print "Oops - took too long!" > > And have i

Re: with timeout(...):

Nick Craig-Wood wrote: > Did anyone write a contextmanager implementing a timeout for > python2.5? > > I'd love to be able to write something like > > with timeout(5.0) as exceeded: > some_long_running_stuff() > if exceeded: > print "Oops - took too long!" > > And have it