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

Re: wakeup events.. thoughts?

On Sun, Aug 29, 1999 at 04:43:08PM -0700, Andrew Morgan wrote:
> 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.

No, you haven't.  That's what I said in brief.

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

That's close to my v1.
The question: at which moment modules register the event handlers?
The second question: how library will make a decision if events handled by
two or more modules happen at the same time?

I spoke about an additional pass through a special module stack for
the registration rather than the event registration during authentication etc.
This stack introduces some order for making a collective decision what to
return to the application.

In my v2 I suggested to avoid callbacks at all.
I consider callbacks as a less natural and clear mechanism than direct calls.
If we create an additional module stack for event processing we may avoid
callbacks at all.  The library sleeps until an event registered by a module
and goes through the module stack in a usual way.  Each module returns a code
appropriate for the moment and the library compose a final code returned to
the application.

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

We haven't had much problems because most applications do not wait for
children at authentication stage.  But I heard about some problems in xdm (if
I remember correctly).

On the event waiting stage many applications will definitely wait for

So authentication modules _should_ register signal handlers,
event processing modules _must_.

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

So we should either
 - implement signal handler registration in libpam, or
 - forbid event processing modules install signal handlers,
   force applications to install handlers without SA_RESTART,
   and implement some hack for special EINTR handling.
Do you see other possibilities?

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

Well, I accept your arguments.
Applications have rights to implement their own event loop.
To avoid 'call non-blocking pam_await_event every 5 secs' approach
we should expose desirable information collected from modules to
applications.  Do you agree?

Best wishes

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