<div dir="ltr">On Mon, Apr 15, 2013 at 8:01 AM, Nick Mathewson <span dir="ltr"><<a href="mailto:nickm@alum.mit.edu" target="_blank">nickm@alum.mit.edu</a>></span> wrote:<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Tor isn't multithreaded like that. Its main thread uses an asynchonous<br>

event loop.<br></blockquote><div style>Ah, I see. </div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'd make a command queue structure that any thread could use to<br>
asynchronously send commands to the main thread, so that the only<br>
change you'd need to make in the main thread would be enough locking<br>
to handle queued commands and to queue replies.  That way the codebase<br>
changes would be much simpler.<br>
<br>
In fact, that's how the controller interface works.</blockquote><div style>I was actually thinking along the same lines but I thought that tor also has a command queue for SOCKS connections so the library could just add data to Tor's queue.</div>
<div style><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Regards,</span><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Navin</span></div></div></div></div>