Thank you for an excellent explanation

Cheers

On Thu, Jun 3, 2010 at 4:26 PM, Nick Mathewson <ni...@freehaven.net> wrote:

> On Sat, May 29, 2010 at 6:44 AM, Sherif Fanous <sherif.fan...@gmail.com>
> wrote:
> > Hi
> > I have the following scenario, and want to verify the expected outcome
> > pthread_wrlock_rdlock(&(server->lock));
> > if (server->is_connected) {
> >     struct send_packets_args *send_packets_args;
> >     send_packets_args = malloc(sizeof (struct send_packets_args));
> >     // Initialize send_packets_args to contain buffer to send, and length
> of
> > buffer to send
> >     event_base_once(base, server->socket, EV_WRITE, send_packets, (void
> *)
> > send_packets_args, NULL);
> >     pthread_wrlock_unlock(&(server->lock));
> >     event_base_loop(base, EVLOOP_NONBLOCK);
> > } else
> >     pthread_wrlock_unlock(&(server->lock));
> > In my callback after I'm done with the sending I perform the cleaning up
> > (free the send_packets_args)
> >
> > Now my question, if at the moment I release my read lock above, the
> > connection to the server is lost and server->socket is closed. Will the
> > callback send_packets get called? I want to know the expected outcome
> > because I need to make sure I'm not leaking memory allocated for the
> > send_packets_args that gets freed as the final step of the send_packets
> > callback.
>
> First off, to clarify, if you want to make sure you're not leaking
> memory when an event isn't called, you pretty much need to use
> event_add() and and event_del() manually, and not trust to
> event_base_once().  If you use event_base_once() and the event never
> triggers, then there's no way to delete it.
>
> But, will it trigger?  I believe so; Libevent seems to report remotely
> closed sockets as EV_READ and EV_WRITE on all the backends I can test.
>  I'm adding a unit test for this to be sure that it holds everywhere.
>
> Stylistically, though, I believe that it's most common to treat the
> availability of the EOF as a -read- event, not a write event.  (That's
> because you detect a close by calling read() or recv() and having it
> return 0.)  I believe some old versions of Libevent may have screwed
> this up on Windows and reported EOF as write instead, though, so be
> sure to test for the behavior you want here if you're using an old
> version.
>
> yrs,
> --
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majord...@freehaven.net with
> unsubscribe libevent-users    in the body.
>

Reply via email to