On Jun 11, 6:56 am, Rhamphoryncus <[EMAIL PROTECTED]> wrote:
> On Jun 10, 3:41 pm, Fuzzyman <[EMAIL PROTECTED]> wrote:
>
> > On Jun 10, 2:03 am, Rhamphoryncus <[EMAIL PROTECTED]> wrote:
> > > So how does .NET deal with the sys.stdout corruption? Does it?
>
> > That has never been an issue for us.
>
> Of course. It's far more likely to hit the underlying blocked I/O
> than the buffer management, unless it's doing a great deal of I/O. Or
> alternatively, they're using some other mechanism to prevent
> interruption during buffer management.
>
>
>
> > > If you've carefully written your code to use only safe primitives and
> > > local state (discarded if interrupted) then yes, it could be
> > > interruptible. At this point you could specially mark that block of
> > > code as safe, leaving the vast majority of other code unsafe by
> > > default. Then again, since you're going to the trouble of carefully
> > > designing and auditing your code you could just make it cancellable
> > > like blocking I/O should be - just by polling a flag at key points
> > > (and you're CPU-bound anyway, so it's not expensive.)
>
> > > The only place I know of that you *need* arbitrary interruption is
> > > hitting CTRL-C in the interactive interpreter. At this point it's a
> > > debugging tool though, so the risk of weirdness is acceptable.
>
> > We use background threads for long running calculations that we know
> > are safe to abort. Resources that need protecting we do with finally
> > blocks which the thread abort honours.
>
> How does that protect code like this?
>
> f = open('somefile', 'w')
> # interruption here
> try:
> ...
> finally:
> ...
>
How does it *not* protect you if you write this instead:
f = None
try:
f = open('somefile', 'w')
...
finally:
if f is not None:
...
> > The calculation is 'coarse grained' (it can call into .NET APIs that
> > can take a relatively long time to return) - so polling for exit
> > wouldn't work anyway. We also run user code and can't expect their
> > code to poll for exit conditions.
>
> Do those .NET get interrupted at arbitrary points? Is this
> "untrusted" user code also audited for correctness? (Although I'd bet
> you simply document what you do and blame the user if something
> breaks.)
>
We don't audit our user code - of course. We do document and assist
them as necessary. Changing to a more restrictive model still wouldn't
meet our use case and put *more* of a burden on our users.
Our situation is not the only one. In general there are situations
where you may want to put a long running calulcation on a background
thread and you *know* that it is safe to interrupt - but Python
currently won't let you.
> I'm not saying it can't be made to work in your specific case - it
> likely does work well for you. I'm saying it can't work *in
> general*. Stretching it out for general use turns those little cracks
> into massive canyons. A language needs a general mechanism that does
> work - such as a polite cancellation API.
Neither *works in general* - polite cancellation *doesn't* work for
our us. That's my point - you probably want *both* for different use
cases. :-)
Michael Foord
http://www.ironpythoninaction.com/
--
http://mail.python.org/mailman/listinfo/python-list
