[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: wakeup events.. thoughts?



Savochkin Andrey Vladimirovich wrote:
> I see two options here:
>  - make pam_sm_event() interface (from the library to modules) completely
> [two versions..]
> What do you think about this two models?

I guess I'm not exactly clear on your two models. Are you saying that
modules may export a pam_sm_event() function, that get invoked by libpam
when pam_wait() is called?

 v1. pam_wait() calls all of the stacked pam_sm_wait() functions to
build an expected-event list (each event being associated with a
call-back)?

 v2. pam_wait() waits for any event and then processes the
pam_sm_event() module stack in order to process the event?

I think I've mangled your ideas here, could you clarify? Thanks.

As an alternative, that carries some of the flavor of (my interpretation
of) your v1. What about adding two new functions to libpam:

  pam_register_event(pamh, callback_fn, event_type, ... );

and

  pam_await_event(pamh, flags);

The first would be used by modules and applications alike to tell libpam
about 'interesting' events to watch out for. The second is used to
invoke the libpam event loop. When an event is delievered, the
callback(s) associated with it are called and, depending upon the return
code for each callback, the event loop might return control to the part
of the program that called pam_await_event() or continue to run in the
event loop, waiting for the next event.

> >  PAM_EVENT_CHILD_EXIT        [More generally, handle any signal]
> >  PAM_EVENT_MEMORY_WRITE      [The essence of conditional variables]

> A module waiting for a child exit is a usual situation.
> Some kind of support is desired.

Actually, this has legacy implications because there are already modules
that fork().

> The special event CHILD_EXIT looks better.
> What if two modules spawn children?  The second module overrides a handler of
> the previous one and bad things start.
> Well, we don't even need _two_ such modules.  The application waits for a
> child too.

Yes, this all looks messy.

> What do you think if the application informs libpam about waiting a child
> before pam_event() call and the library will handle SIGCHLD?

It makes me nervous, but its beginning to look more inevitable.

> Otherwise it isn't safe for modules to touch signal handlers at all.

Yes. There is a real possibility of chaos if we get this wrong.

> > Finally, we should also support applications with their own event loop,
> > we could have a non-blocking way of invoking pam_await_timer(), that

:*) s/timer/event/

> > returns immediately if there are no events pending.
> 
> I prefer applications to add their own events for pam_await_event().
> Busy loops su.. hmm not very efficient.

But there are things like X-applications that operate in an event loop.
I believe it would be easier for the X-application to poll
pam_await_event() than libpam to poll X. There are other networked
applications (lsh and one of the ftp servers, beroftp or proftp I
forget), that operate in an IO event loop. I guess if we provide a hook
for watching for typical events, we could leave this 'who owns the real
event loop' decision to the application implementers.

Cheers

Andrew



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []