Handling ptr1/ptr2 free (minor nitpicks)

Jeffrey Johnson n3npq at mac.com
Fri Jun 16 07:46:17 CEST 2017


I’m attempting a low-level interface to libeio, building my own eio_req and calling eio_submit.

Both of these issue 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).

There; 2 relatively minor issues that are fundamental libeio API design choices.

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 see bio_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/554fd4ff/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/554fd4ff/attachment.bin>


More information about the libev mailing list