Re: [Libevent-users] Proposal for libevent-2 to provide functions to hide event structure details

[Pavel Pisa <ppisa4lists@xxxxxxxxxx>]

Hello Nick,

On Saturday 16 January 2010 06:49:02 Nick Mathewson wrote:
> On Fri, Jan 15, 2010 at 5:48 AM, Pavel Pisa <ppisa4lists@xxxxxxxxxx> wrote:
> > int event_assign_fd(struct event *ev, evutil_socket_t fd, short events);
> > int event_assign_callback(struct event *ev, void
> > (*callback)(evutil_socket_t, short, void *), void *arg);
> > void *event_get_callback_arg(struct event *ev);
> > int event_assign_persist(struct event *ev, int persist);
> > size_t event_struct_size(void);
>
> I think event_struct_size() is a fine idea.  Most programs won't need
> it, but the ones that do will be glad to have it.

Great

> I also agree that there should be functions to get every feature of an
> event that can be set using event_assign().  Fetching the callback arg
> (and the callback, and maybe the event flags) is a missing element of
> our current feature set.  Maybe the right choice is an
> 'event_get_assignment' that yields (via assigning to pointers passed
> as arguments) everything that was passed to event_assign/event_new:
>
>    void event_get_assignment(const struct event *ev, struct event_base
> *base_out,
>        evutil_socket_t *fd_out, short *events_out, void
> (**callback_out)(evutil_socket_t, short, void *),
>        void **callback_arg_out);

OK, this is generally good choice because it mirrors event_assign
argument sets and allows straightforward creation of event copy
in case of need to duplicate it to another tread event poll for example.
It has some unnecessary overhead for my use intent, but it is
mostly problem of my choice to have more fine grained API, which
has drawback, that more calls are required even for most common
event setup case. This is right, that you do not want to extend
API to fill needs of negligible uses cases.

> Individual convenience functions for individual arguments might be
> good too.  This is a proliferation of functions, but not a crazy one.
>
>
> I don't see the rationale behind event_assign_fd() and
> event_assign_callback(), though.  It seems to me that, given a
> non-added event, you could just use event_assign() to reassign all the
> fields if you wanted it to refer to a different callback or fd.  If
> you want to see what some of the old fields were, you could use the
> appropriate accessor functions to see what they used to be.

Generally agreed as described above. My specific use would significantly
benefit from event_get_callback_arg(), because use of event_get_assignment()
would be unnecessary overhead in these cases. But if this functionality
is not provided, I can add pointer into my wrapper, which would mean
field duplication (-), but would slightly speedup code for arm with timeout
and base destroy cases (+). So I have no preference there and adapt
code according to your choice.

As for timeouts, I am sure if it changed for libevent-2, but according
to my reading libevent-1 did not re-trigger/restart timeout counting
when there are some data exchanged. My API expect yet opposite case.
I would like a much to have function to restart timeout or even change
event timeout triggering time without need of event_del event_add sequence.
Because these operations means relatively costly operations for some
mechanisms cases (epoll for example).
It is not necessary to manipulate by epoll/FD for these cases, it is enough
to delete and insert timeout into timers queue/RB-tree.
I think, that even other use cases could profit from such possibility.

Thanks,

          Pavel
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.