[Libwebsockets] [libwebsockets] #15: Removal of public close...

Trac trac at libwebsockets.org
Fri Feb 15 15:09:04 CET 2013


#15: Removal of public close...
------------------------------------+--------------------
  Reporter:  Joakim                 |      Owner:  agreen
      Type:  defect                 |     Status:  new
  Priority:  major                  |  Milestone:
 Component:  libwebsockets library  |    Version:
Resolution:                         |   Keywords:
------------------------------------+--------------------

Comment (by agreen):

 We already pass this user pointer into the callback as a parameter in
 every callback except:

 1) LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION - the wsi is not established
 yet, the job is to accept or veto the protocol requested for the
 connection, so user data is not relevant

 2) LWS_CALLBACK_PROTOCOL_DESTROY - not called about any WSI, one-off
 indication the whole protocol is being destroyed and can deallocate
 anything it held for the session

 3) as you pointed out, the external poll callbacks put wsi->sock in there

 IIUI, it means that we would only want to use this proposed new
 wsi->user_space accessor in one of these three spots... the only spot it
 actually makes sense is the external poll callbacks, because the other two
 either have a un-established wsi or a NULL wsi.  I dunno why we want to
 touch user_space data during external poll pollfd management, but there we
 are.

 If you see eye to eye with that, how about we move the wsi->sock into the
 @in callback argument for the external poll handling?  That will directly
 provide the user pointer in an obvious and clear way right in the callback
 where it's legal to use, without adding a new api which looks to the
 unwary might get you a user pointer in another thread from an externally
 held wsi, etc.


 For your other question, on the one hand, you should get a CLOSE callback
 every time, and it won't come until the next time you service the lws
 sockets.  On the other hand, user_space is malloc'd by the library and
 freed by the close.  If you hold an external pointer to it, it'll be
 invalidated by the close too, having set things inside it to NULL or not
 dereferencing it at all will blow a segfault.

-- 
Ticket URL: <http://libwebsockets.org/trac/ticket/15#comment:11>
libwebsockets <http://libwebsockets.org>
libwebsockets C library



More information about the Libwebsockets mailing list