Also, if you go with the sleep around and it turns out to not work out
well, then we'll tackle that problem when we come to it. =) Keep in mind
we're [EMAIL PROTECTED] yet and still have room to "play". ;) We have a lot of
great testers who are good about reporting problems/bugs! (and many
thanks to all of you!)
Daniel
--
"The most addictive drug in the world is music."
- The Lost Boyz
> I have put up "current tarballs" at:
> http://www.vorpalcloud.org/tarballs/
>
> As for the multithreaded sendSNAC question, I'm not 100% sure. I tried
> throwing a sleep in there to see how it went and it seems to behave in a
> reasonable manner. I really don't have a good answer for you though. =/
>
> Daniel
>
> --
> "The most addictive drug in the world is music."
> - The Lost Boyz
>
>> If a current tarball found its way onto a webserver I could try to
>> integrate ratelimiting into it.
>>
>> But an implimentation question: currently I did ratelimiting by making
>> the
>> SNAC sending call sleep() until sending the packet would not go over the
>> limit. Is there a better way to do this? Would it be better to span a
>> new
>> thread (or five, one for each rateclass) to send packets out of a queue?
>>
>> I suppose the real question is whether the calls to sendSNAC() are
>> themselves multithreaded, as causing the whole thing to sleep() is a bad
>> idea. Does a delay in sendSNAC() block other things happening
>> internally?
>>
>> ~Chris
>> _______________________________________________
>> py-transports mailing list
>> [EMAIL PROTECTED]
>> http://mail.jabber.org/mailman/listinfo/py-transports
>>
>
> _______________________________________________
> py-transports mailing list
> [EMAIL PROTECTED]
> http://mail.jabber.org/mailman/listinfo/py-transports
>
