On Jun 11, 7:56 am, Fuzzyman <[EMAIL PROTECTED]> wrote:
> 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:
>
> > 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:
> ...
Yeah, that should be safe, so long as the open call itself is
protected.
> > > 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. :-)
Yeah, but mine's less icky. ;)
I think the ideal for you would be a separate process. I'd also
suggest a restricted VM only in a thread, but that probably wouldn't
work for those long-running .NET APIs. Now, if those long-
running .NET APIs did polite cancellation, then you could combine that
with a restricted VM to get what you need.
I think what bothers me is, even if those external APIs support polite
cancellation properly, your forced interruptions will bleed over and
mess them up. There needs to be a way of containing it better.
Writing them in another language (as C is used for most of Python's
builtins today) isn't a reasonable requirement.
--
http://mail.python.org/mailman/listinfo/python-list
