Re: Handling ptr1/ptr2 free (minor nitpicks)

[Marc Lehmann]

On Fri, Jun 16, 2017 at 01:46:17AM -0400, Jeffrey Johnson  wrote:
> 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.

That's more like a result of the implementation and not a fundamental design
choice.

> 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”.

What purpose would that have? Whether you reuse the memory for the request
or not, you have to initialise the structure, no?

> 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 ...

Well, it's probably too late for that.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev

Handling ptr1/ptr2 free (minor nitpicks)

[Jeffrey Johnson]

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
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev