Handling ptr1/ptr2 free (minor nitpicks)

Jeffrey Johnson n3npq at mac.com
Fri Jun 16 07:54:04 CEST 2017



> Begin forwarded message:
> 
> I’m attempting a low-level interface to libeio, building my own eio_req and calling eio_submit.
> 
> Both of the issues below are easily dealt with, but are perhaps surprising, if attempting to
> manage/reuse an eio_req object (I have a refcounted eio_req pool for allocation) without embedding.
> 
> The 2 relatively minor issues that are fundamental libeio API design choices are:
> 
> 1) req->pri being remapped from 0 -> 4 (by subtracting EIO_PRI_MIN) and hence changed from what was sent.
> 
> 2) freeing ptr1/ptr2 before calling (*req->destructor).
> 
> The code looks like this
> 
> static void
> eio_destroy (eio_req *req)
> {
>   if ((req)->flags & EIO_FLAG_PTR1_FREE) free (req->ptr1);
>   if ((req)->flags & EIO_FLAG_PTR2_FREE) free (req->ptr2);
> 
>   EIO_DESTROY (req);
> }
> 
> Ultimately the decision is (imho) whether an eio_req object is “stateful”, and the change
> to req->pri and the magic free of ptr1/ptr2 is a “feature” of the interface, or whether the
> management of an eio_req through a low level interface with an opaque destructor should
> leave as much as possible as is, and leave allocation/free to the caller.
> 
> Either API design choice is consistent.
> 
> But (at least) indicate that the memory has been de-allocated already by setting ptr1/ptr2 to NULL
> and perhaps by toggling the flags bits, if you choose to view eio_req handling as “stateful”.
> 
> I’d suggest that the better low-level API would be to leave the eio_req object inputs unchanged
> to the greatest extent possible. JMHO ...
> 
> hth
> 
> 73 de Jeff
> 
> 	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20170616/9c9b8932/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1790 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20170616/9c9b8932/attachment.bin>


More information about the libev mailing list