On 12/12/06, Kevin Sanders <[EMAIL PROTECTED]> wrote:
On 12/11/06, Zhu Han <[EMAIL PROTECTED]> wrote:
Ah, that's a good point. We're pretty sure it was 0, which means
allow as many as physical processors, but if it was 1, that would
explain it. Another clue with this is that if the first thre
Ya.. I think some better documentation is in order.. I also am thinking
that you might want to convert gettime() to evgettime() and export it
for use with the library to keep those that might have a system that
doesn't have CLOCK_MONOTONIC, which defaults to CLOCK_REALTIME or even
defaults to gett
Thank you. I have applied the patch to trunk.
Niels.
On 12/11/06, Nick Mathewson <[EMAIL PROTECTED]> wrote:
Hi, all! This patch fixes a bug in nameserver timeouts in evdns.c.
Previously, we would count the number of successive requests that had
timed out in a row for each nameserver, but we w
Hi, all! This patch fixes a bug in nameserver timeouts in evdns.c.
Previously, we would count the number of successive requests that had
timed out in a row for each nameserver, but we would never actually
reset the timeout count to zero. This, obviously, would create
problems: see the Tor bugtrac
Kevin Sanders wrote:
I haven't looked at you're code yet, sorry I don't know the function
names. I'm referring to when the IOCP thread calls GQCS and sees the
read completion, it calls a read completion callback I believe? If
someone made a blocking call from this callback (the callback is
runn
On 12/11/06, Zhu Han <[EMAIL PROTECTED]> wrote:
On 12/11/06, Kevin Sanders <[EMAIL PROTECTED]> wrote:
> I'm not sure what limit your asking about. Are you talking about the
> GQCS milliseconds timeout value? In any case I'm not sure. He was
> using his own IOCP code.
I mean the value of Nu
On 12/11/06, Toby Douglass <[EMAIL PROTECTED]> wrote:
Kevin Sanders wrote:
> The lesson here is you don't want the IOCP threads doing anything
> except issuing async IO, popping completions and a quick state machine
> change (see below) and issue another async IO if needed. If more
> processing
On 12/11/06, Toby Douglass <[EMAIL PROTECTED]> wrote:
Ah. Go look at socket_iocp_add_socket(). You'll find the very first
call to socket_internal_iocp_read() occurs at the end of *that*
function, which gets the read ball rolling.
Yeah, you're right! I didn't pay attention to the prior
so
Niels Provos wrote:
> Please, think about that before flaming.
I don't think anyone is flaming anyone here right now. It seems to be a
pretty scholarly, polite and reasonable discussion.
___
Libevent-users mailing list
Libevent-users@monkey.org
http:
Zhu Han wrote:
I have made some mistake when I type the above words. I just mean you
should
issue socket_internal_iocp_read firstly and then let the callbacks to
consume the data. However, in your code, you invoke the callbacks before
socket_internal_iocp_read. See the following snippet:
s
Kevin Sanders wrote:
On 12/10/06, Toby Douglass <[EMAIL PROTECTED]> wrote:
I've not added support for writes, because I
think people generally issue blocking writes, since non-blocking means
that if you return from a function which issues a send you have to
ensure the lifetime of the buffer you'
On 12/11/06, Kevin Sanders <[EMAIL PROTECTED]> wrote:
I'm not sure what limit your asking about. Are you talking about the
GQCS milliseconds timeout value? In any case I'm not sure. He was
using his own IOCP code.
I mean the value of NumberOfConcurrentThreads* *when invoke
CreateIoCompleti
12 matches
Mail list logo