tevent immediate events

[simo]

On Fri, 2009-03-13 at 15:45 +0100, Stefan (metze) Metzmacher wrote:
> simo schrieb:
> > On Fri, 2009-03-13 at 14:54 +0100, Stefan (metze) Metzmacher wrote:
> >> simo schrieb:
> >>> On Fri, 2009-03-13 at 12:40 +0100, Stefan (metze) Metzmacher wrote:
> >>>> Hi,
> >>>>
> >>>> We have some usecases for directly triggered timed events
> >>>> where we can't do proper reporting of allocation errors.
> >>>>
> >>>> I'd like to propose to add new event class for immediately triggered
> >>>> events:
> >>>>
> >>>> typedef void (*tevent_immediate_handler_t)(struct tevent_context *ctx,
> >>>>                                            struct tevent_immediate *im,
> >>>>                                            void *private_data);
> >>>> struct tevent_immediate *tevent_allocate_immediate(TALLOC_CTX *mem_ctx);
> >>>> void tevent_schedule_immediate(struct tevent_context *ctx,
> >>>>                                struct tevent_immediate *im,
> >>>>                                tevent_immediate_handler_t handler,
> >>>>                                void *private_data);
> 
> Volker: are you fine with this interface?
> 
> >>>> The caller allocated the tevent_immediate structure once and can
> >>>> then schedule() it when needed. Once the event is triggered it's
> >>>> detached from the tevent_context again. The caller can reuse it later.
> >>>>
> >>>> if the schedule function is called while the event was still scheduled,
> >>>> it will be detached from the old tevent_context and attached to the new
> >>>> context.
> >>> Can you please clarify better what problem are you trying to solve with
> >>> this scheme?
> >>> Maybe give an example that shows why tevent_add_timer does not work and
> >>> how this solves the problem.
> >> in tevent_queue, we use a timer event to trigger the next event.
> >> currently we only do this for the first event, when it's added to the
> >> queue, so we can report tevent_add_timer() returning NULL.
> >> The bad thing is that we trigger the following events from deep inside
> >> of the talloc destructor of the finished tevent_req. I'd like to avoid
> >> that, as it would mean we have event nesting. I'd like to always
> >> trigger the next request via an immediate event. That means the
> >> talloc destructor of the finished request would just schedule
> >> the immediate event and that should not fail as we have no way to
> >> handle an error there.
> >>
> >> I'd also like to use the immediate events in my tsocket code
> >> for triggering read and write events on virtual sockets, which don't
> >> have a fd. It simplifies the code a lot, if I can use call
> >> a void function to schedule the event.
> >>
> >> There were also a lot of other situations where I liked to have
> >> a way to add immediate timers without adding a lot of logic to handle
> >> possible errors in the past.
> >>
> >> I also thought about adding a tevent_allocate_timer()/
> >> tevent_schedule_timer(), but Volker proposed to add a separate
> >> class of events, as it's to confusing to have to behavior for
> >> tevent_timer objects. And I like the idea to split them.
> > 
> > I see, it seem a very good idea, but I guess one constraint is that the
> > caller must make sure to not free the immediate event in a destructor as
> > well.
> 
> The immediate event will also have destructor, like the timer event
> which will detach the event from the context, so the caller can free it
> at any time, as for every other event.

ok.

> > One more question.
> > I've seen that struct tevent_fd, tevent_timer, tevent_signal share most
> > of the structure, with minor differences. And I imagine tevent_immediate
> > would also do that. Wouldn't it make sense to have one structure (with
> > unions inside and a marker that specify what it is for) and call it
> > "struct tevent_event" or something to that effect for the public API ?
> > Or is there any value in exposing different types ?
> > Once you have tevent_immediate I guess sometimes you may want to use the
> > same handler for either immediate or timer events and having different
> > prototypes for the handlers would require you to have wrappers to do
> > that.
> 
> tevent_fd, tevent_timer and tevent_signal are more or less low level
> interfaces and should not be mixed.
> 
> tevent_req is the higher level to call async functions, where all
> callbacks have the same prototype. We have tevent_wakeup_send/recv()
> for the higher level, to avoid the low level interfaces.

Make sense.

> I planing to write a README to tevent, like the talloc_guide.txt.
> I already started to do that for tsocket (not finished yet)
> http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=ca60e4eae868a43136078af95a82a419fae85735

Thanks this will help a lot.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>