<div dir="ltr">On Sat, Apr 13, 2013 at 10:42 AM, wac <span dir="ltr"><<a href="mailto:waldoalvarez00@yahoo.com" target="_blank">waldoalvarez00@yahoo.com</a>></span> wrote:<br><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"><br>
Hi Navis:<br>
<br>
Good to hear you built it. I have a working library with a defined API but is not re-entrant. It can connect with a server over Tor circuits and transmit/receive data but nothing is re-entrant at all. So the same Tor thread must be used for all of that ATM.<br>

<br>
I can fetch webpages like that however and can also do some limited chit-chat over IRC.<br>
<br></blockquote><div style>I didn't realize that you already had it working :) I guess I will wait untill you post the code.</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 attempted to add some locking to some of the data structures but that is insufficient. For instance lists and buffers. Hash tables are complex. They are defined with some macros in order to make them generic overcoming some limitations of C language but they are less than maintainable IMHO. So I was thinking to replace them with another one already built with a similar license but re-entrant. Found a very good one.<br>
</blockquote><div>I thought Tor already had some level of locking since multiple applications can connect to it at the same time via SOCKS. I completely agree about replacing the macros though.</div></div></div></div>