state-threads
[Top] [All Lists]

Re: Using with LDAP

To: state-threads@xxxxxxxxxxx
Subject: Re: Using with LDAP
From: Dan Melomedman <dmelomed@xxxxxxxx>
Date: Mon, 16 Jul 2001 14:58:31 -0400
In-reply-to: <000701c10de0$24b372a0$dbbfa8c0@xxxxxxxxxxxxxxxxxxx>
References: <000701c10de0$24b372a0$dbbfa8c0@xxxxxxxxxxxxxxxxxxx>
Sender: owner-state-threads@xxxxxxxxxxx
User-agent: Mutt/1.3.18i
You'll have to use helper processes for LDAP library functions. You can
communicate between your main server process and your helper functions
via socketpair(). Those asynchronous LDAP functions are AFAIK use
blocking I/O. The reason you need helper processes it to avoid blocking
your server process and therefore all its threads as per state threads
documentation.

The only problem I see with helper processes is the high overhead of
fork(). It seems like you'll be forking a process per LDAP search, which
is very expensive, and IMHO diminishes the original purpose of a high
performance multithreaded server. I am guessing you could have your
helper processes pre-forked(), spawning additional helpers as needed,
but this still wastes resources.

Does anyone have a better suggestion? Would it be possible to run two
separate servers one being the main server, and the other being the LDAP
helper server which would do IPC via a local UNIX socket for the purpose
of avoiding fork()? How would we differentiate between requests from 
different state threads? The LDAP search server could be multithreaded
using alternate threading libraries like pthreads or GnuPth.

>     We are planning to use state threads library in our server application
> which serves login requests. The UserID/Passwords are stored in LDAP. So the
> Server needs to do network io with LDAP via the Netscape directory SDK for
> C, which has asynchronous functions. The state threads documentation states
> that only state thread i/o routines should be used. Is there any way to use

<Prev in Thread] Current Thread [Next in Thread>