[Zope3-dev] twisted zope

[Phillip J. Eby]

At 02:42 PM 7/28/03 -0400, Shane Hathaway wrote:
>Phillip J. Eby wrote:
>>And there's yet another possible approach...  Have Zope depend on 
>>specific I*Reactor interfaces in place of asyncore, but don't necessarily 
>>depend on Twisted itself.  I'm not sure if this meets the intended goals 
>>for Zope/Twisted integration, but it's a useful first step.  If this is 
>>useful, PEAK has an "UntwistedReactor" class that implements a useful 
>>subset of the Twisted reactor interfaces, enough to be able to have a 
>>select loop and scheduled callbacks.  It's ZPL/PSF licensed, so you can 
>>steal it fair and square.  So, as long as the existing Zope 3 server code 
>>just expects to be woken up by asyncore for reads and writes, it should 
>>be pretty adaptable to the reactor interface, at which point it could be 
>>hooked into Twisted or into a Zope 3 mini-reactor.
>
>That sounds great.  Do you have a ViewCVS link?

Interface is at:

http://cvs.eby-sarna.com/PEAK/src/peak/running/interfaces.py?rev=HEAD&content-type=text/vnd.viewcvs-markup

See 'IBasicReactor'.

For the implementation, see:

http://cvs.eby-sarna.com/PEAK/src/peak/running/scheduler.py?rev=HEAD&content-type=text/vnd.viewcvs-markup

It's class 'UntwistedReactor'.  The implementation depends on peak.binding, 
but not in any deep way.  You should be able to replace most of the 
'binding.bindSomehow' attributes with an __init__ method.  The class also 
expects to have a 'logger' attribute that's a PEP 282-compatible 
logger.  Last, but not least, you can interpret the 'self._delBinding()' 
calls as meaning that the specified attribute should be reinitialized.

You can pretty much ignore the rest of the module for your purposes, except 
the _Appt class, which is a private class representing a scheduled callback.


>The one feature that we'd need beyond the simple "wake me up when 
>something is ready" interface is the trigger interface.  It lets a thread 
>tell the main thread to wake up immediately.

Ah.  I didn't implement that, as I haven't needed it for anything.  I 
believe you can emulate it over the primitives I've supplied, though, as I 
believe Twisted normally does it by setting up some kind of pipe or socket 
that the thread writes to, with a reader hooked up on the reactor.  The 
reader just throws away the meaningless data, but of course the main thread 
has now been reawakened from its select() call.