[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] libevent with EV_WRITE question



Thank you for an excellent explanation

Cheers

On Thu, Jun 3, 2010 at 4:26 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
On Sat, May 29, 2010 at 6:44 AM, Sherif Fanous <sherif.fanous@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.