Thank for the reply.<br>I have no idea about the behaviour regarding the GIL.<br><br>But I found that my problem is due to the python wrapper: this is not a bug but it cannot allow threading.<br>What happens is that the python &#39;dispatch&#39; call the underlying C &#39;dispatch&#39; (of course) in one python thread. But doing that, python do not control any more this thread, and thus the interpreter is blocked by this call.
<br>If I add a timer event in the loop with a callback doing nothing (createTimer(lambda fd,evt,obj: sleep(0)).addToLoop(timeout=0)), the C code call back the python code and the other trheads can be executed ... but why use event if there is a loop on null timer doing nothing!?!
<br>So, if there is nothing that can be made in the wrapper for that (I have absolutely no idea), I guess I have to discard either threading either libevent of my program.<br><br>Which lead me to another question about architecture design.
<br>My first (libevent) thread is a socket server, getting requests from all clients, and putting them in a queue. My second thread take request one by one, processes it, and create a reply that it put in a queue used by the first thread. I wanted 2 threads (or 2 thread pool) because the application logic of the second thread imply accessing the DB and doing a fair bit of computation that is not easy to split in events in such a way that we can ensure the response time.
<br>If I give up the threading, I could have the same model using processes, but then I need a communication channel between the 2 processes. What can be used which would be efficient? UNIX socket? mkfifo?<br>My other alternative is to replace libevent by the twisted framework which allow an event based server model, but threading for non asynchronous calls.
<br><br>Any comments?<br><div><span class="gmail_quote">On 6/8/07, <b class="gmail_sendername">Ka-Hing Cheung</b> &lt;<a href="mailto:Ka-Hing.Cheung@riverbed.com">Ka-Hing.Cheung@riverbed.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, 2007-06-07 at 16:02 +0800, Ludovic Coquelle wrote:<br>&gt; Hi,<br>&gt;<br>&gt; I use libevent through the libevent-python wrapper.<br>&gt; If it is not the relevant mailing list to ask, please point me to the<br>&gt; right place ;)
<br>&gt;<br>&gt; I wanted to write an event loop, running in its own thread, while<br>&gt; another thread can do something else.<br>&gt; Whatever I&#39;ve tried, the first call to &#39;dispatch&#39; block all the others<br>
&gt; threads (from what I understand).<br>&gt; I wrote something like:<br>&gt;<br>&gt; def evhello(obj, name):<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; # dummy callback: print hello every second<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; print &quot;hello&quot;, name<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; if obj:
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; obj.addToLoop(timeout=1)<br>&gt;<br>&gt; def evstart(name, next=None):<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; evB = libevent.EventBase() # new base for each thread<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; event = libevent.createTimer(lambda fd, events, obj: evhello(obj,
<br>&gt; name))<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; event.setEventBase(evB)<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; event.addToLoop(timeout=1)<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; evB.dispatch()<br><br>Does dispatch() here give up the global interpreter lock?<br><br>-khc<br><br></blockquote></div>
<br>