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