[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [Libevent-users] RPC: patch for cancelling requests
- To: libevent-users@xxxxxxxxxxxxx
- Subject: Re: [Libevent-users] RPC: patch for cancelling requests
- From: Nick Mathewson <nickm@xxxxxxxxxxxxx>
- Date: Fri, 25 Feb 2011 13:35:44 -0500
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: libevent-users-outgoing@xxxxxxxx
- Delivered-to: libevent-users@xxxxxxxx
- Delivery-date: Fri, 25 Feb 2011 13:35:51 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=5V1WGchFVPsBfYeNiwgf+GySzklhAuSiwjOBNGjsTuU=; b=Drucrfs0XX7v71slZ+UuFusQUMEYPHyKUgdVwQ5z3sicz1hIQSJmLqzVxmTPl9zYBE kT9/K8wmFZxDyir5An6cY/653e5pCFpx2M2LUcmPZyXfNui9NLlAO1WffoBRT/jE9ZE0 OltTyo4DBqmGJciLnP2oK7zSeWcYGeuTCNgzM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=e/OMnjkv8e2iAsTF/JT2ly9bgwzG1VyafkxqdcYWEG06aihuTf1w3YrrGCYZSbTUE+ f1NbC5okcREfOH4IS4q9oCffMB1x7QVPHTKZcQpJN/YMRGOvCdkEcLVTQ0rJe0BAm112 bK+Pg5thzXMMF5zIEPYnOQhpPIvG4LpYZ0jgA=
- In-reply-to: <4D67CD0C.7060707@xxxxxx>
- References: <4D67CD0C.7060707@xxxxxx>
- Reply-to: libevent-users@xxxxxxxxxxxxx
- Sender: owner-libevent-users@xxxxxxxxxxxxx
On Fri, Feb 25, 2011 at 10:38 AM, Christophe Fillot <cf@xxxxxx> wrote:
> Hello,
>
> The following patch allows to delete a RPC pool (with evrpc_pool_free()),
> including
> all requests which have already started. The user-defined callback is called
> with
> a new status (EVRPC_STATUS_ERR_ABORTED) which allows to properly release
> memory
> used for message requests and replies.
>
> It also fixes some possible memory leaks in evrpc_schedule_request(), when
> an error
> is encountered. The problem I described in my previous message should also
> be fixed.
>
> I checked different scenarios (with or without hooks, timeouts, connection
> failures...) using Valgrind, everything seems ok. The "regress" test code
> seems
> also fine (all tests are OK).
>
> Please let me know your opinion about it, I'm not yet familiar with the
> libevent
> code :)
It looks plausible, though I haven't had a chance to review it too
closely yet. I would like to have unit tests for this particular case
too, if at all possible.
One thing to watch out for in this code is the fact that the "next"
pointer in the request is apparently used for keeping track of the
request's neighbors on any of the requests list and the
started_requests list, so it's important to make sure when adding a
request to one of these lists, it isn't already on the other one.
(I'm not sure whether the code already makes sure of this; I wish the
existing evprc code were better about documenting its invariants.)
The new "aborted" status code makes me slightly twitchy. Adding a new
status code like this means that, potentially, old callbacks that
don't know about the new callback will stop working. I think that
it's okay in this one case, since the only way to get the new status
code (if I'm understanding you right) is to free an evrpc instance
with multiple pending requests, which would not have worked before at
all... so no previously working code will break, which would make a
new code okay.
yrs,
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.