Re: [Libevent-users] Abnormal delay on read

[Viallard Anthony <viallard@xxxxxxxxxxxxxxxxxxxxxx>]

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.