On Jun 11, 6:49 pm, Rhamphoryncus <[EMAIL PROTECTED]> wrote:
> 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. ;)
>
But requires more code. :-)
> 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.
No - we need to pull a large object graph *out* of the calculation
(with no guarantee that it is even serializable) and the overhead for
marshalling that puts using multiple processes out of the running.
What we *want* is what we've got! And it works very well... None of
the problems you predict. :-)
We may at a future date look to using AppDomains to sandbox user code
- but haven't needed to yet.
Michael
http://www.ironpythoninaction.com/
>
> 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
