Timeouts in HEAD ldap code.

[Volker Lendecke]

On Fri, May 27, 2005 at 05:22:14PM -0700, Jeremy Allison wrote:
> Volker, I need to talk to you about the timeouts in the
> HEAD LDAP code and the changes you made in lib/util_sock.c
> to allow them.

You're the expert on the signal stuff, so I really appreciate your input here.

> You were using the non-EINTR safe versions of select, and
> so any incoming tdb message would cause the LDAP operation
> to abort (you were relying on an alarm() to generate a
> signal if the operation took too long). I don't think this
> is the correct thing to do, we need to ensure that the
> LDAP read/write ops time out correctly given "endtime",
> 
> To do this the LDAP socket needs to be in nonblocking
> mode (IMHO), which we're not currently doing.
> 
> Essentially, the LDAP code doesn't look async signal
> safe to me, and we need to fix that.
> 
> Either that, or you need to split off your read_data_until()
> write_data_until() functions and put them into the LDAP code
> to make sure they're not used from the generic SMB socket
> calls.

Are you referring to lib/smb_ldap.c? The LDAP parsing/unparsing stuff? As far
as I know this is not yet really used anywhere. I've programmed
idmap_smbldap.c that uses these functions, but that's about it I think. In
Samba 3 this has not gone anywhere yet, maybe it will sometime, but not yet.

This LDAP lib does not use alarm, and I'd be happy to see read_data_until and
write_data_until corrected.

I'm much more concerned with smbldap.c, the stuff that uses the alarm()
function. The whole reason for the homegrown ldap libraries was the inability
to get the OpenLDAP libs to *reliably* timeout after a certain amount of
time. I don't think they are ready to run over async sockets, or am I wrong
here? In my test of quite a while ago, the OpenLDAP libs did not check for
EINTR and happily returned if the read/write calls were interrupted. This
might change however.

From my point of view there's only two ways to get really reliable timouts and
fully async operation: Fork a child or do it on our own. I'm not sure which of
those is better in terms of ugliness...

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20050528/c2595610/attachment.bin