tor_user wrote: >> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerOS >> >>> I'm not really sure how an application which relays TCP traffic >>> (albeit encrypting/decrypting it) can consume this amount of RAM. Is it >>> really normal? >> On your operating system, yes. >> >> If there exists a new version of NetBSD with a reentrant >> gethostbyname_r(), let us know and we'll special-case it. > > I supposed you could get cron to restart the tor service hourly, or > daily > as a workaround. That is what I was thinking, but I decided against it since I wouldn't want to connect through such a system myself (since I would need to restart it hourly in order to get some kind of stability from it). My TOR exit node does get a lot of traffic, and in case someone is downloading something rather large, I don't want to interrupt it periodically. Sometimes my node can run for a whole day, other times just half an hour, before crashing. Restarting it each hour feels evil. I'd rather like to find a real solution to the problem. Mainly, getting a working gethostbyname_r(). Btw.. What is the origin of gethostbyname_r()? Does it exist in all common/mainstream unicies? As a side note, I don't understand why the calls to gethostbyname() can't be mutex'd on BSD systems, rather than just switching over to an all fork'd design. Are there other calls which are affected as well? OS/2 was designed for multi threading from the ground up, but at some odd times I did actually encounter API:s which weren't thread safe. Instead of kicking off a bunch of separate processes, I simply protected those API:s with a mutex semaphore. An ugly workaround, but not as ugly as launching an army of processes, imho. But then again, I'm unaware if there are other issues adding to the problem. -- Kind regards, Jan Danielsson
Attachment:
signature.asc
Description: OpenPGP digital signature