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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Fri, Jan 15, 2010 at 5:48 AM, Pavel Pisa <ppisa4lists@xxxxxxxxxx> wrote:
> Niels and others,      # try 4 hopefully correct now and freehaven.net online
>
> please, consider addition of functions to allow access more fields
> of struct event a way ensuring compatibility with future libevent version.
> The list of possible functions prototypes follow. Implementation is attached
> at the end of e-mail.
>
> 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.

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);

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.


> The rationale:
>  - hide event structure implementation/layout. Application using these
> functions
>   instead of direct access can keep compatibility with future libevent
> versions.
>   To achieve this separation, functions can not be implemented outside of
> libevent.so

Agreed.

>  - the function event_get_callback_arg allows read stored callback argument
>   without need of its duplication in additional field of some other
> structures
>  - the functions event_assign_fd, event_assign_callback and
> event_assign_persist
>   allows to allocate event for use with known base in advance and fill FD
>   and monitored events later. This can be interresting for RT applications,
>   where malloc should not be part of code executed in critical code paths for
> example.

I think that using event_get_assignment [as proposed above] and
event_assign would above two goals.

>  - the event_struct_size functions allows to check for incompatible event size
>   between libevent version used for program compilation and runtime used
> version.

Yes.  This should go in.

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