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

Re: wakeup events.. thoughts?

On Fri, Aug 27, 1999 at 09:17:39AM -0700, Andrew Morgan wrote:
> Savochkin Andrey Vladimirovich wrote:
> > Well, the library can ask each module
> >   - if it wants to be called periodically and with what period; or
> >   - if it wants to be called on an event on file descriptor(s).
> This brings up the question of what events are interesting and is there
> a finite set of them that we could support and be reasonably confident
> that people can do everything they are likely to want? Can we make a
> list?
>   1. an event on a filedescriptor
>   2. some sort of periodic event
> seems like a good start. I'd like to be able to accommodate an event
> like the demise of a specified child process id, and Sun seemed pretty

Waiting for a child would be useful.
The only problem is how to implement the waiting in the library in parallel
to poll()ing?

> keen on supporting 'conditional-variables' (which seem to be a sort of
> select mechanism on the contents of memory: 
> http://www.mit.edu:8001/people/proven/pthreads_man.html#pthread_cond_wait)
> You suggest that the library would ask the module about events like
> this, perhaps it might be better for the module to ask libpam to watch
> out for an event? In this case old modules would be unaffected by this
> additional support in libpam.

Well, the module certainly should inform the library that it hasn't finished
its task (e.g. authentication) and wants to wait for an event.
The module may return something like PAM_WAIT_EVENT code.

How to pass the event information is a not very important question for me.
The module may set the information by a special library call before returning
PAM_WAIT_EVENT.  Or the library may ask the module about this information by
a special call seeing PAM_WAIT_EVENT.

> > The library accumulates modules wishes into a single table and calls poll(2).
> This seems like a good place to start.
> > continue poll()ing.  Termination of the application can be handled via a
> > signal.
> This seems ok, but how this wakes up libpam (to return from pam_event())
> seems problematic. The application is justified in believing it 'owns'

EINTR returned by poll() is a request to call modules.

> all of the signal handlers, so having libpam intercept one seems like
> asking for confusion. Perhaps, we can use something like the conditional

I realize it.  It's a difficult problem.
Probably we're forced to support in libpam something like registering of
signal handlers.  The library will call every registered handle receiving a
signal i.e. making the signals "broadcast".  This solution raises other set
of problems:
 - existing modules and applications may require to be modified to use the
 - modules and applications should be prepared that the signal handler is
   called when nothing (related to the module or application) has happened.
   For instance, SIGCHLD handler should be ready to an occasion that the
   child hasn't really finished.
Well, it's really a difficult problem.
But we need to solve it somewhere.  Otherwise applications and modules can't
rely on signal handlers at all because they may be intercepted in any moment.

> variable thing to as a way to communicate that the server received a
> signal that it would like to act on?

The idea of conditional variables doesn't look good to me at the moment.
Waiting on a variable will require either
 - CPU consuming busy loop (very bad)
 - spawning threads (not so good)
 - or use existing implementation which implements one of the methods above.
I don't like spawning threads because there are no reliable way to do it
without compatibility problems.  Using clone(2) isn't a portable way.
Different thread libraries are even worse.  The fact that there are more than
a single library makes the whole idea problematic even not taking into
account how dirty their code usually is.  My colleagues having looked at glibc
threads were shocked.  So they implemented their own small library to be used
for very business critical tasks (accounting of clients' traffic for payments
etc).  So threads in a library like libpam looks impractical at this stage.

Best wishes
					Andrey V.

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