[Date Prev][Date Next]
Re: connection management changes
- To: "email@example.com >> OpenLDAP Devel" <firstname.lastname@example.org>
- Subject: Re: connection management changes
- From: Emmanuel LÃcharny <email@example.com>
- Date: Tue, 08 Jan 2013 19:25:00 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=+eXZg8xmigkgXtseA1Oj6nw3P+kZXhJYEq+A6/EjOeI=; b=VM3Sx7mqaDqkaeiXiUoRzoTKryXgLGZy7qfWFj8iwUNl8dUHLgOSc2si+vw+giVncm Ua5CODCgchbAhDtPCtnG3XNzFUU4KB8QTO41TrohOamsF8XEPXQf47I6JsrW29B/Ar4r 5/a4UQ6sGmXQrZnZjY64cuklIweez356U4Y2FU5C9if+J6ITrwPDkKPtNSZmdQfMQoLa dXRT54kUfUjQQJZwykD5AOgDmdW3GR8tUEsD8QecaOEv+jBdJfmnleI+O/ynQI39LBxX HnUQ4uIoqfFBN4WoYqDjklzwPwFF0y97eUdQuJZtmbmRldteGiznzfj1pywem3jMwZIQ 48qg==
- In-reply-to: <firstname.lastname@example.org>
- References: <50EAD4F0.email@example.com> <firstname.lastname@example.org>
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
Le 1/7/13 5:35 PM, Hallvard Breien Furuseth a Ãcrit :
> Howard Chu writes:
>> We listen for writable sockets if a write attempt returns incomplete. There's
>> a pair of mutexes and condition variables used to synch up here between the
>> writing threads and the listener thread. It's quite a lot of lock overhead. As
>> far as I can tell the main reason we do this is so that we can stop a writer
>> thread on demand instead of having it just block forever in write().
> slapd seems to use non-blocking socket descriptors if it can, so it's
> rather that write() to a full socket would otherwise do a busy loop
> write()ing 0 bytes until there was room.
If you try to write to a full socket, you'll get a 0 as a result to a
write attempt, and then, you will have to enqueue the data and set the
write_op type so that epoll_wait wakes up when the socket is ready.
When the socket is ready for write, the thread will check the queue, and
will try to empty it. If it succeeds, the write_op is unset and you are
done. Otherwise, the socket is bloked again, and you enter in a new
wait. Of course, never forget to unset the write_op flag, otherwise the
epoll_wait() will exit immediately, and you'll get a busy loop again...