Subject: Re: O_NONBLOCK

Re: O_NONBLOCK

From: William Ahern <william_at_25thandclement.com>
Date: 2005-05-17

On Tue, May 17, 2005 at 01:56:22PM -0400, codemastr wrote:
>
> ----- Original Message -----
> From: "William Ahern" <william@25thandClement.com>
> To: <c-ares@cool.haxx.se>
> Sent: Tuesday, May 17, 2005 1:18 PM
> Subject: O_NONBLOCK
>
>
> >Has anyone run into trouble with a blocking read? I woke up this morning
> >to
> >find a test server blocked on a recv(2) call. The _only_ recv(2) I can
> >find
> >in my code is from Ares, and I now realize that Ares doesn't set any of
> >it's
> >sockets non-blocking.
> >
> >Can anyone think of any issues that might arise if I made the sockets
> >non-blocking and dealt with errno=EAGAIN/EWOULDBLOCK in read_udp_packets()
> >and read_tcp_packets()? I can't think of any off-hand.
>
> Well open_tcp_socket does set O_NONBLOCK. However, it does not seem that
> the open_udp_socket does. From your tracing, are you able to see whether
> the socket that blocked was TCP or UDP?
>
>

Here we go! A blocking recv(2). However, it seems that the socket got some
sort of exceptional condition, because `events' is 0 for the
ares_catch_event() call. I'll have to look at the libevent code to see how
it sets EV_READ and EV_WRITE. However, ares_catch_event() FD_ZERO's the read
and write descriptor sets, and only marks the descriptor if EV_READ or
EV_WRITE is set for that set from `events', so I'll have to investoage why
ares is calling read_udp_packets().

In any event, arguably it may be prudent to still make UDP sockets
non-blocking even if there's no evidence it's technically okay not to.
I'll keep investigating.

#0 0x40af1356 in recv () from /lib/libpthread.so.0
#1 0x0807cc97 in read_udp_packets (channel=0x8098d50, read_fds=0xbfffeea0,
    now=-1073746400) at ares_process.c:242
#2 0x0807c8c4 in ares_process (channel=0xa, read_fds=0xbfffeea0,
    write_fds=0xbfffee20) at ares_process.c:60
#3 0x08072687 in ares_catch_event (fd=142, events=0, c=0x808e0d4)
    at lookup.c:664
#4 0x08075bbd in event_process_active () at event.c:202
#5 0x08075d6d in event_loop (flags=1) at event.c:288
#6 0x08067eca in slave_exec (s=0x808b208) at slave.c:287
#7 0x08068162 in slave_fork (sg=0x808b018) at slave.c:355
#8 0x08068539 in slave_group_open (opts=0xbffff040) at slave.c:506
#9 0x08069bb4 in server_fork () at server.c.m4:446
#10 0x08069c53 in server_start () at server.c.m4:460
#11 0x0804f8d7 in reset () at main.c:70
#12 0x08052fa1 in signal_catch_ev (sig=-512, events=8, null=0x0) at sig.c:26
#13 0x08075bbd in event_process_active () at event.c:202
#14 0x08075d6d in event_loop (flags=0) at event.c:288
#15 0x08075bdd in event_dispatch () at event.c:214
#16 0x0804fab0 in main (argc=5, argv=0xbffff264) at main.c:233
#17 0x40b4b80c in __libc_start_main () from /lib/libc.so.6

- Bill
_______________________________________________
http://cool.haxx.se/mailman/listinfo/c-ares
Received on Tue May 17 22:07:49 2005