> > def doThings():
>
> > myDeferred = someting_that_blocks();
>
> > def doThingOne(result1):
> > print("doing ThingOne", result1)
> > return sqrt(result1)
> > myDeferred.addCallback(doThingOne)
>
> > def doThingTwo(result2):
> > print("doing ThingTwo", result2)
> > return another_thing_that_blocks(result2)
> > myDeferred.addCallback(doThingTwo)
>
> > def doThingThree(result3):
> > print("doing ThingThree", result3)
> > return result3*3.1415927
> > myDeferred.addCallback(doThingThree)
>
> > return myDeferred
>
> > Thats it.
>
> This is easy to read for someone who already knows twisted, but I
> have a hard time convincing myself that it's easier to read than
>
> def doThings();
> result1 = someting_that_blocks()
> print("doing ThingOne", result1)
> result2 = sqrt(result1)
> print("doing ThingTwo", result2)
> result3 = another_thing_that_blocks(result2)
> print("doing ThingThree", result3)
> return result3*3.1415927
I think you've hit a wonderful point. One of the true nightmares of
threading is that it can be hidden.
This was one of the difficulties that CORBA had early on as well...
since the proxy object being called caused all kinds of communications
to occur... sometimes even calling through a series of processors back
to itself. Unfortunately, the single threaded server was blocking
waiting for a response for itself, and it would deadlock...
Now, of course, it couldn't be the developers (no names but their
initials are MITRE), so CORBA was designated "not ready for prime
time"...
The point is that regardless of how clean the interface "appears", not
understanding whats going on is death. I claim (and of course, this
is widely accepted) that threads are a true nightmare in the hands of
those who don't understand.
Importantly the system you're building is extremely generic and nobody
with any experience with real systems would suggest that threading is
a rational approach to addressing IO blocking... in fact, its
typically the poster child for how not to use threads.
(I could post a few hundred links on this issue but googling "threads
considered harmful" would likely give you a good start)
This is all before we get into the issue of where did you spawn the
thread... what is the other "main" thread doing, what is going to
happen to exceptions, what strategy to join with this thread is to be
used etc...
But I digress. The point is there are things to learn and they need
to be understood. Syntatic issues in the above example are irrelevant
because things are actually happening which need to be understood.
>
> I wonder if this has contributed to the lack of contributions to the
> notebook relative to other parts of Sage.
The Notebook has a major problem. The pexpect code is opaque and
kludgy and includes strings of python code which get injected into the
spawned notebook process amongst other issues. There's also lots of
handling of "corner cases" which have evolved over time. In my not so
humble opinion, it should all be ripped out and replaced with a proper
asynchronous interface. This could be accomplished with very little
effort, but it hasn't been a priority and it would require William's
buy-in and assistance. Until very very recently, this wasn't
feasible.
> Also, the painful part is
> often to write the "xxx_that_blocks," especially if it's "blocking"
> because it's computationally expensive, rather than waiting on an
> external event that naturally triggers a callback.
Right, understanding whats going on is often important. (Not a
popular American concept and lies at the heart of the accelerating
decline of the US... again I digress)
> One needs to
> manually chop the computation into small enough bits that no one
> piece takes too long, and this can't be hidden from the implementer.
> (Either that, or run the computationally intensive part in a separate
> thread/process and set up a callback, but the one isn't avoiding
> multiple threads...) And the twisted model is non-deterministic
> (hence harder to debug) as well.
Yea, its fairly easy to break something if you work hard enough at
it :-)
>
> I have to admit I'm playing a bit of the devil's advocate here, I've
> used both twisted and threads (though admittedly I've never used
> Python threads) and the twisted folks have implemented a very nice
> model for dealing with this kind of thing. When there's a lot of
> synchronization or global state threading can be a pain.
> But I think
> it's far from obvious that the twisted model is a better fit (though
> the notebook is a controller for multiple processes and simple
> shuffler of data back and forth, so there is a strong case here).
Well, I suppose reasonable people can disagree.
(not that I'm reasonable... but I'm pretty sure I'm right)
-glenn
>
> - Robert
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
