--- "Mrs. BrBrisby<mrmrsrbrisbyinimhrorgwrote:
> On Tue, 2003-10-14 at 13:14, Salvador FaFandi�orote:
> > Another requirement is that, as multiplexing is based on select,
> > I can not use callbacks (even if I can accept running LDLDAPalls
> > or queries synchronously)
>
> Using select() (or IO::Select) does not prevent callbacks from
> working.
> You do have to enable asasyncode for the Net::LDLDAPandle and call
> $ldldapsync() [or examine sub _rerecvrespnside LDLDAPm] whenever
> activity is available.
>
> I presume you're already aware how to get the socket using
> $ldldapsocket()
Oh, no, no, sorry, I think that I have not been able to express the
problem with clarity. Let my try again:
I don't mind ququeringDLDAPynchronously and stopping the server until
it returns.
The problem is with callbacks that require information that has to be
retrieved from the remote client (ApAppClient To send or receive data
from there I would have to enter again the "select" main-loop from
the callback but it is not possible because there are several clients
working asynchronously.
Let my use a diagram to show why:
- C1 and C2 are clients.
- ML is the main-loop
- ML1 and ML2 are new instances of the main-loop that have been
entered from the callbacks
ML
|
| ML1
C1 query LDLDAP |--callback1-->|
| ML2
C2 queries LDLDAP |--callback2-->|
|
C1 returns |
data for callback1 ??? <------|
can you see the problem?
Anyway I already have a solution for the callbacks problem that is to
fork a new prprocesso run the LDLDAPuery completely asasynchronously
But the main problem continues to be how to proxy the authorization
handshaking to the client.
Cheers,
- Salvador.
