tevent immediate events

[simo]

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

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.

Simo.

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