EXPERIMENTAL: tevent_kqueue support

Stefan (metze) Metzmacher metze at samba.org
Tue Feb 26 23:06:50 MST 2013

Am 27.02.2013 01:34, schrieb Jeremy Allison:
> On Tue, Feb 26, 2013 at 01:35:58PM -0800, Jeremy Allison wrote:
>> On Tue, Feb 26, 2013 at 09:39:16PM +0100, Stefan (metze) Metzmacher wrote:
>>> Am 26.02.2013 20:53, schrieb Jeremy Allison:
>>>> On Fri, Feb 22, 2013 at 08:46:31PM +0100, Stefan (metze) Metzmacher wrote:
>>>>> I spend the last days, fixing some bugs that made autobuild unstable
>>>>> when we use the poll backend. (About 30-40 private autobuilds...)
>>>>> My current work in progress is available under
>>>>> https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-tevent2
>>>>> and
>>>>> https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-tevent2
>>>>> I'll try to add some more tests which test the specific behaviors
>>>>> regarding triggered events,
>>>>> e.g. that an event without flags and remaining bytes in the socket
>>>>> doesn't cause
>>>>> a 100% cpu loop and similar things.
>>>> Ping ! Wonder where you are with this ? I have some OEMs
>>>> that would like to see this finished so we can get the
>>>> epoll fix into a winbindd release.
>>>> Is there anything more I can do to help ?
>>> I'll try to propose a patchset for master tomorrow,
>>> it would be good to get some feedback then.
>>> In the meantime it would be good if you could take a look
>>> at my comments to this:
>>> TODO: Regression test to ensure that a tevent backend can cope with
>>> separate read/write events on a single fd.
>>> ...
>>> TODO: why (fde_wcount - fde_count < 256) ???
>>>       if we get TEVENT_FD_WRITE we should not block
>>>       we should also not read if we don't get TEVENT_FD_READ,
>>>       because this will block.
>>> https://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=610afde264816ece80fcdaca13d39ab3bf86c7b7
>> That code was already written carefully to do exactly what
>> it does :-).
>> Without using threads it's really easy to get yourself
>> blocked on a pipe. I'll have to do more testing to see
>> if it's true that writable is cleared when a pipe is
>> full.
> Ok, I have something that works at least with poll
> and correctly detects pipe full without blocking
> in a single threaded process. Needs to do the
> same with select and epoll of course.

Are you talking about changes in the tevent backends
or our tests?

> If you want to propose the existing patchset including
> this test (which proves the multi-fd change works
> with epoll) I'll create an additional patch on
> top that splits the callbacks out into 4 separate
> ones that should work cleaner.

I think we should squash this additional patch for master.

...and I'd like to see your code:-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130227/c07f110e/attachment.pgp>

More information about the samba-technical mailing list