[Libwebsockets] query for InputBuffer in Callback

Andy Green andy at warmcat.com
Wed May 18 06:22:09 CEST 2016

On 05/18/2016 11:52 AM, techi eth wrote:
> Thanks for quick response.
> Please clarify below.
> 1.Buffer received during LWS_CALLBACK_RECEIVE is not per-wsi buffer.Is
> that buffer allocated dynamically ?
> When that buffer is getting freed ?

You can just look at the sources, right?

If you think there is a memory leak, valgrind should provide some 
evidence I can look at.  But I seriously doubt it.

> 2.Do we really need per-wsi buffer if we don't have any extension to
> support ?

Lws doesn't know how many extensions it will meet or what they will do 
in what order.

So it starts off with a per-wsi buffer and allows the extension to 
reallocate if what it needs to output is a processed version of the 
per-wsi buffer, this is the meaning of eff_buf.

If you care enough about that to provide a patch that can select to use 
the per-thread buffer if extensions disabled, please send it along.


> On Wed, May 18, 2016 at 9:12 AM, Andy Green <andy at warmcat.com
> <mailto:andy at warmcat.com>> wrote:
>     On 05/18/2016 11:30 AM, techi eth wrote:
>         Hi,
>         I have query regarding inputbuffer in web socket callback.
>         Is that buffer is the same which is initialize during
>         lws_callback_function registry while context creation ?
>         If it is not the same then once it is received in callback how is
>         freeing that buffer.
>     Different buffers are used for 'in' at the user callback depending
>     on the callback.  I assume you're really thinking about
>     There is indeed a per-service-thread (by default, == per context)
>     temp buffer that's used for things that will definitely be finished
>     with before we finish the current socket service, that's destroyed
>     when the context is.  Any service activity can use that as a scratch
>     buffer.
>     But for ws connections, there is also a per-wsi buffer allocated to
>     be the size of the rx_buffer_size member of the negotiated
>     protocol.  This is destroyed when the related wsi closes.
>     The per-wsi rx buffer is needed for, eg, due to an extension like
>     permessage-deflate, the whole rx buffer cannot be consumed before
>     returning to the event loop... consider the inflated rx is being
>     passed onward via another output socket, and the output socket is
>     full.  So it must be able to hold the remaining rx associated with
>     the wsi until next service for the wsi.
>     -Andy
>         Thanks
>         _______________________________________________
>         Libwebsockets mailing list
>         Libwebsockets at ml.libwebsockets.org
>         <mailto:Libwebsockets at ml.libwebsockets.org>
>         http://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list