[Twisted-Python] Synchronous @inlineCallback interpreter
Clayton Daley
clayton.daley at gmail.com
Thu Apr 24 20:28:04 MDT 2014
[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: </pipermail/twisted-python/attachments/20140424/669f4e3e/attachment-0002.html>
More information about the Twisted-Python
mailing list