[Twisted-Python] Blocking on deferreds during unit tests (e.g. deferredResult)

[Jp Calderone]

On Tue, 10 May 2005 08:27:27 -0400, Kevin Dangoor <dangoor at gmail.com> wrote:
>On 5/8/05, Itamar Shtull-Trauring <itamar at itamarst.org> wrote:
>> On Sat, 2005-05-07 at 11:02 -0400, Kevin Dangoor wrote:
>>
>> > Using gthreadless, one could interface sqlobject and Twisted's db
>> > interface to take advantage of the work done in Twisted Enterprise to
>> > make sqlobject-style database access safe for Twisted. (It's
>> > undoubtedly possible without gthreadless, but it seems like it would
>> > be a lot easier)
>>
>> Nope, that wouldn't work. greenlets do *not* make blocking APIs ot
>> block.
>
>I understand that... The Twisted Enterprise database api, if I
>understand correctly, uses the Twisted threadpool to wrap otherwise
>blocking database calls behind new calls that return deferreds.
>sqlobject, on the otherhand, was written in a traditional
>(non-callback) style.
>
>My thought was to use gthreadless to create an interface between
>Twisted Enterprise (ADBAPI?) and sqlobject. For sqlobject, it would
>look just like the blocking interface it was used to. But, it would be
>able to take advantage of the thread management already done by
>ADBAPI.

  SQLObject doesn't implement DB-API, so it is not usable with t.e.adbapi.  The interface it presents is not very amenable to isolation in a separate thread, so any mechanism to using it asynchronously will be awkward.

  Jp