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
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
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:
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
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 is
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
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
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
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
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
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 thread
11 matches
Mail list logo
