On Mon, May 21, 2001 at 03:53:09PM -0700, Mike Abbott generated a stream of 1s
and 0s:
> > I am going to be using OpenLDAP 2.0.x libraries for now.
> > Does this mean that a process could be potentially blocked, even though
> > OpenLDAP does have asynchronous search functions?
>
> That depends on whether OpenLDAP ever issues any blocking I/O calls,
> whether to disk, network, or a pipe.
>
Yes, OpenLDAP uses blocking I/O, network only.
> > If so, what would be
> > an efficient and state-thread safe method of IPC, if I split the server
> > into two (one being the POP3 server, the other being help processes that
> > will accomplish LDAP authentication and return a response to a thread
> > via IPC). I would also have the helper processes eventually do disk read
> > I/O for the server.
>
> Use the State Thread Library's I/O functions over a pipe or TCP socket
> pair. See
> http://oss.sgi.com/projects/state-threads/docs/notes.html#disk
>
> If you port OpenLDAP to use the State Thread Library's I/O functions
> instead of native functions (st_write instead of write on sockets) it
> can run in the same process. If it does disk I/O though the asymmetric
> architecture performs better.
> --
> Michael J. Abbott mja@xxxxxxx www.repbot.org/mike
Porting would probably be too much of effort to justify what I am
trying to accomplish it looks like quite a bit of code.
Besides I don't think anyone else is interested in OpenLDAP
supporting state threads :(.
Do I have to use st_ functions in the help processes also (forked from
main daemon processeses), OR can I have the help processes run separarately
as a second daemon communicating over a named pipe or a BSD domain socket
by any chance?
|