Hi!

On Thu, Jan 22, 2009 at 10:01:35AM -0500, arthur wrote:
>> Just a note: For tracking a non-blocking connect, you use a *write*
>> event, not a *read* event. ...

>Thanks Hannah and Niels. That is the point, I didn't register write cb
>for the connecting fd (with my old event_add code, the notification came
>from read :))

A notification *can* come for read: On error or server greeting or the
server closing the connection again (e.g. a server timeout when the
server is tired of waiting for the client sending something). You might
just wait longer than you really want to.

>Here another q regarding bufferevent (with listening tcp fd). Now I got
>connection event from error cb (with error what==0x21)

Please decode the numerical values again (if it's errno values, they're
specific to the platform you're using! but even if it's libevent values,
it's just not as readable as the symbolic constants or several of them
or'ed together).

>to accept a new
>client. Is this the expected behavior? Do I need read/write cb for
>listening fd?

You use a read event (and as you noticed yourself in the subsequent
mail, you can use vanilla events). A listener fd becomes readable if you
can call accept() at least once without blocking (or yielding only
EAGAIN if it's non-blocking).

On Thu, Jan 22, 2009 at 10:27:27AM -0500, arthur wrote:
>> Here another q regarding bufferevent (with listening tcp fd). Now I got
>> connection event from error cb (with error what==0x21) to accept a new
>> client. Is this the expected behavior? Do I need read/write cb for
>> listening fd?

>Comment my own q: maybe I shouldn't use bufferevent for listen fd (which
>won't send/receive). I see http.c uses event_add. 
>Thanks anyway. Arthur

Right. A listener socket is good about only for accept (or close,
later), except for perhaps a few esoteric things (which I'm less aware
of, dunno whether you can query things on the next connection to be
accept()ed before accepting it on some platforms, for example, or query
the number of pending connections).

Kind regards,

Hannah.
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users

Reply via email to