On Aug 21, 2009, at 4:18 PM, ghtdak wrote:
>
>>
>>> Of course, this is the penultimate reason that going multi-
>>> threaded in
>>> python is insane... not only do you get the opportunity to learn all
>>> about synchronization and thread management, you also enjoy non-
>>> deterministic bugs which only take days or weeks to solve whereas
>>> more
>>> conventional logic bugs take many many minutes, sometimes even
>>> hours.
>>> (From a Keynesian economics perspective, going multi-threaded is
>>> justified just by the added work)
>>
>> My point was that there is benifit going mutli-threaded: you don't
>> have to
>> manually set up callbacks/fork every time you might block. Whether
>> this
>> simplification is worth the other complexities depends on the
>> program at
>> hand (and probably the programer as well).
>
> I disagree. Once Twisted is in place (and I'm not a paid Twisted
> spokesman) you'd be very surprised at how easy it becomes...
> particularly given the capabilities of python.
>
> A trivial (and likely syntactically incorrect) example
>
> 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 wonder if this has contributed to the lack of contributions to the
notebook relative to other parts of Sage. 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. 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.
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).
- 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
-~----------~----~----~----~------~----~------~--~---
