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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
