Timeouts in HEAD ldap code.

[Jeremy Allison]

On Sat, May 28, 2005 at 10:04:22PM +0200, Volker Lendecke wrote:
> 
> 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.

The problem is the changes you made to HEAD to cause read_data() to
depend on read_data_until() broke the callers of read_data() until
I made read_data_until() use the signal-safe sys_select_eintr() and sys_read()
calls.

Now read_data_until() isn't quite right as it calls sys_read() which will
block indefinately as it ignores EINTR.

We need to separate out the read paths for the smb calls, which need
to be signal safe (using the EINTR ignoring wrapper functions) and
to create parallel read paths using read_data_until() which allow
signal interrupts to return EINTR. Then from functions that depend
on the end_timeout parameter and the SIGALARM signal we must call
a wrapper that blocks the rt-signals for oplocks and the SIGUSR1
signals for messages and then re-enables them afterwards.

Right now we have a mix of the two in HEAD and this doesn't work.

You're getting away with it as it's very rare you get an oplock
break signal or tdb message signal when you're in the LDAP calls,
but if you want to use the LDAP library code that isn't signal
safe you need to wrap it in BlockSignal()/UnblockSignal() pairs
and use the EINTR signal-unsafe sys_select() and read() calls.

The receive_smb calls need to use an alternate data path that
uses the sys_select_intr() and  sys_read() EINTR-safe calls.

Let's discuss this - and work out who will do the code conversion.

Jeremy.