[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Abnormal delay on read



On 09/04/2014 09:57 AM, Azat Khuzhin wrote:
Unless you have very-big buffers, and if you external functions are
fast, this callback must work fast (at the first glance).
Could you attach debugger to process when you see slow downs, and post
backtrace here (What I'm wonder is it enter the read callback or not)


Do you want a strace output or libevent debug messages ? The two ? I wonder this because I think the quantity of all these messages will be a quite bit huge.


Moreover, after read callback is called, I don't have any remaining data in
the input evbuffer (I don't see the log messages).

You mean that at the first line of you read callback:
evbuffer_get_length(bufferevent_get_input(bev)) === 0 ?


Actually, I talk about the evbuffer_get_length(evbuf_in); at the end of the function. Sometimes ago, searching why the messages processing were shift, I thought maybe the messages were queued in evbuffer as I don't read all data in it in read callback like you see. But I didn't see the log message "sock %p: remaining %zu byte(s) of data". So, the problem is somewhere else.

Writing this email, I'm wondering if the evbuffer_get_length() function
works in all contexts ? I mean, I disable the read callback when the
"socket" is writing for example.

AFAIK it must work in all contexts, this is just reading
buffer->total_len + locking, but if you disable read event then you will
not recieve any new data, and maybe you are expecting it?


I disable read event when I call talk_socket_write() function actually. In this function, I disable read and enable write. I write the data in the output evbuffer. I enable read again (without read timeout) and disable write in write callback. I think it's the correct way to do when you want listening incoming requests, doesn't it ?

Regards,
Anthony.

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.