<div><span class="gmail_quote">On 5/5/05, <b class="gmail_sendername">Patrick Mézard</b> <<a href="mailto:pmezard@gmail.com">pmezard@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello,<br>I have several questions about twisted reactors and extending the twisted<br>framework with new asynchronous APIs.
<br><br>1- What is the status of the IOCP reactor? Is it stable? If it is, is there any<br>reason for not selecting it as the default reactor for win32 NT platforms?</blockquote>
<div> </div>
<div>The IOCP reactor doesn't support spawnProcess, among other things, which is why I currently can't use it. The author (PenguinOf in IRC) was also going to submit a list of bugs he knows about. Here are the notes I jotted notes down in IRC.
</div>
<ol>
<li>always resets connection instead of closing it nicely</li>
<li>need half-close support</li>
<li>need fancy optimizations, like multiple threads and multiple outstanding read requests per socket</li>
<li>redesign proactor</li>
<li>reactor.shutdown doesn't cancel</li></ol><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">2- I am considering the integration of a custom database API (like Berkeley DB)<br>in a twisted application. I could easily wrap the API in a C++ python module and
<br>access it synchronously from twisted, at least in a prototyping phase.<br>Obviously, if the blocking calls are too long it would make the whole framework<br>completely useless. Then, the calls could be made from twisted managed threads.
<br>Assuming the module code was written to minimize GIL contention it would<br>probably greatly improve the situation. The most efficient solution would be<br>to plug the asynchronous API directly into the reactor:<br><br>
Is it possible to extend reactors with new asynchronous API implemented in<br>separate client modules?<br><br>With my little knowledge of the twisted framework and quick glances at the<br>selectreactor and iocpreactor implementation, I think the answer is no.
<br>The practical solution would be to duplicate the reactor code and extend it<br>with the new API calls.<br><br>I do not know if it would be easy or not to provide a pluggable asynchronous<br>framework *at C module level*. Basically, the reactor is nothing else than a
<br>thread-safe event queue with a (post/get)-event API. If this abstraction can be<br>implemented at C level, then plugging new asynchronous handlers would be clearly<br>doable, _iocp.c is a good example for that. Now, I am not really knowledgeable
<br>(yet) about python C module coding, and I guess it is not exactly easy to bind<br>C callbacks from one python C module into another using normal python code as<br>glue. In the end, this is just another plugin/component system like COM to
<br>write so...<br><br>Any thoughts?<br><br>Patrick Mézard<br><br>_______________________________________________<br>Twisted-Python mailing list<br><a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com
</a><br><a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br></blockquote></div><br>