[Twisted-Python] Synchronous @inlineCallback interpreter

[Clayton Daley]

[apologize in advance if this creates threading issues as I picked digests
when I signed up not realizing it would make it difficult to reply to
threads]

Sorry I wasn't more clear.  My thought is to write a version that uses the
same @inlineCallback name and supports the same syntax (to eliminate the
need to rewrite code).  However, I don't mean the synchronous version to
actually use deferreds at all.  All I want the synchronous version to do is
"ignore" the yields (likely by sending the output right back in after the
block clears)... and treat the returnValue() as a return.

That way code written in the @inlineCallback syntax can be used by a
synchronous or asynchronous consumer.

Clayton Daley


On Thu, Apr 24, 2014 at 8:14 PM, pierre at jaury.eu wrote:

>
Le 2014-04-25 01:45, Clayton Daley a écrit :
>* I imagine rewriting this to the following:
*> >*     @classmethod
*>*     @inlineCallbacks
*>*     def from_id(cls, id):
*>*         doc = yield db.get_document(id) # blocking/async db call
*> >*         self = cls._new_document(doc) # always synchronous
*>*          yield self.__init__() # blocking/async call
*>*         returnValue(self)
*> >* places. I've read that the @inlineCallback code is complicated so I
*>* figured I'd run the idea by the experts before diving down that rabbit
*>* hole.
*
I am no expert, but the code for inlineCallbacks looks pretty
straightforward, except some special cases handled down the way.

>* Does anyone see any obvious pitfall? I'm happy to do the legwork
*>* to try and build it, but I'd also welcome any pointers from your (no
*>* doubt extensive) experience writing the twisted version.
*
I would mostly argue about a semantic problem. inlineCallbacks help
asynchronous code *look* like synchronous code thanks to the sequential
writing. It is however essentially asynchronous and does return a
Deferred.

I do not see any immediate technical pitfall here. I would however be
very careful and double think my design if I were to use Deferred
objects as part of a blocking process.

kaiyou.


On Thu, Apr 24, 2014 at 7:45 PM, Clayton Daley <clayton.daley at gmail.com>wrote:

> I have a modular application that communicates over RPC connections (with
> both sync and async server/clients available).  I want to migrate some of
> the modules over to Twisted. Currently, all modules inherit important
> utility functions from a parent class.  On paper, I now need two versions
> of this parent class (synchronous & asynchronous) to be inherited by
> modules of the respective types.
>
> I'm looking for ways to maximize the common code between the two versions
> of the parent object. One that comes to mind (motivating the subject of
> this post) would be to write a synchronous interpreter for @inlineCallback
> calls.  For example, here's a synchronous factory function from the parent
> class (already partly reconfigured to be friendly to my idea):
>
>     @classmethod
>     def from_id(cls, id):
>         doc = db.get_document(id) # blocking db call
>         self = cls._new_document(doc) # synchronous initialization stuff
>         self.__init__() # module init code is custom and may block
>         return self
>
> I imagine rewriting this to the following:
>
>     @classmethod
>     @inlineCallbacks
>     def from_id(cls, id):
>         doc = yield db.get_document(id) # blocking/async db call
>         self = cls._new_document(doc) # always synchronous
>         yield self.__init__() # blocking/async call
>         returnValue(self)
>
> Assuming the db connector and init function are appropriate to the
> environment, my gut reaction is that this could (when combined with a
> synchronous implementation of the decorator) run correctly in both places.
> I've read that the @inlineCallback code is complicated so I figured I'd run
> the idea by the experts before diving down that rabbit hole. Does anyone
> see any obvious pitfall? I'm happy to do the legwork to try and build it,
> but I'd also welcome any pointers from your (no doubt extensive) experience
> writing the twisted version.
>
> Thanks in advance!
>
> Clayton Daley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20140424/669f4e3e/attachment.html>