Re: [Boost-bugs] [Boost C++ Libraries] #7837: Datagram packing of UDP BufferSequences

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7837: Datagram packing of UDP BufferSequences
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-12-30 07:58:35

#7837: Datagram packing of UDP BufferSequences
-----------------------------------------+----------------------------------
  Reporter:  rafael_gago_81@…            |       Owner:  chris_kohlhoff            
      Type:  Feature Requests            |      Status:  new                       
 Milestone:  To Be Determined            |   Component:  asio                      
   Version:  Boost 1.52.0                |    Severity:  Showstopper               
Resolution:                              |    Keywords:  udp; asio; scatter-gatther
-----------------------------------------+----------------------------------

Comment (by rafael_gago_81@…):

 Two things.

 First that the message above was meant to be an edit, I don't know what
 happens to my browser.

 The code I posted is obviously very very wrong, as there is a
 "non_blocking_sendto" async/non-blocking call, I don't know hod did I
 missed that (tired?), it couldn't be patched at a so higher level.
 Unfortunately I can't edit both previous messages.

 Yesterday I had a look at the Windows sources, it seems to me that the
 calls would need to be divided in the socket calling code, there are two
 ways to go that I can see:

 Invoque the handler as many times as datagrams are sent, so the
 bytes_transfered variable don't need to be synchronized at higher levels.

 The first with problem with this is that to be coherent with the current
 design it would be needed to call the handler as many times too in case of
 failure.

 Another one is that the functions inside the operation object would need
 to be reentrant, as the same object could potentially be called from many
 threads.

 And then for doing it in this way the handler would need to be deallocated
 only when the last call is made, so it would require synchronization.
 Maybe storing the operation structure in a shared pointer with a custom
 deleter would do the job, the difficult part is having a place to store it
 avoid dynamic memory.

 The other approach would be to use one operation object that fakes two
 operation objects, the data bulk would be using the first one, which
 doesn't deallocate, and the last datagram would use the real one and
 invoque the completion handler, just one time, that looks cleaner than the
 above.

 I think that is safe to assume that the last operation will finish the
 last one on both platforms, what isn't that clear is that the last
 operation finish could would be executed the last, so some type of
 synchronization is needed. That would add synchronization primitives again
 at the operation level, a thing that looking at the internals of the
 library belongs to lower layers.

 Another problem with this approach is that bytes_transfered needs to be
 synchronized, but this is minor compared with the above problem.

 There maybe is a third way...

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7837#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.