Re: Are kqueue events "round robin"?
Re: Are kqueue events "round robin"?
- Subject: Re: Are kqueue events "round robin"?
- From: Påhl Melin <email@hidden>
- Date: Tue, 7 Apr 2009 11:47:13 +0200
2009/4/6 A.M. <email@hidden>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Apr 6, 2009, at 7:12 AM, Påhl Melin wrote:
>>
>> I would expect the kqueue not to be filled up with EVFILT_READ and
>> EVFILT_WRITE events, but to have only one of each whenever the buffers
>> are "ready". But the question is if I'm guaranteed to have alternating
>> read and write events? Or if I get starvation of any kind? I don't see
>> anything about this matter in the man pages so I'm curious if it's
>> specified at all?
>
> There are no guarantees made, but in my usage, I have not experienced
> starvation under conditions similar to yours. You may be overthinking this.
> Just try it and you can address starvation later, if it occurs.
You are totally right. I'm probably overthinking this, but I haven't
seen much detailed information on kqueue:s on Google, books and
elsewhere and I didn't want to spend unnecessary time implementing
something bound to fail.
>>> I haven't experienced any event starvation situation, but in case you have,
>>> the best approach would be to implement an array over kqueue. Simply read
>>> more than one event into your own queue and you can algortithmically decide
>>> which events to process (and then remove them from the array- obviously it's
>>> no longer a queue). But don't waste time implementing this approach
>>> unless you are indeed experiencing starvation.
>>
>> Thanks, I hadn't really considered returning multiple events and make
>> my own decision. But it would of course be easier if a reasonable
>> decision was already made by the kevent() call.
>
> If you only have one socket (thus, only one kqueue ident filter), I wouldn't
> bother with this suggestion at all.
>
>>> Since one thread can only do so much, if you have lots of socket or sources,
>>> then you may want to break their processing into separate thread (kqueue is
>>> thread-safe and works well across multiple threads). Even a single socket
>>> read and write events could be broken out across threads.
>>
>> That's interesting. I what sense is kqueue thread safe? Can I wait on
>> the same kqueue in two different threads, each calling kevent() or do
>> I make two kqueue:s, one with a read filter and the other queue with a
>> write event on the same socket descriptor?
>
> You can add filters to kqueue from different threads, kqueue-block on the
> same events on different threads, use multiple kqueues from different
> threads, block on the same ident with different filters. It all works.
Wow, I would never imagine kqueue:s being _that_ "robust". I would
certainly have added multiple mutex blocks etc. to do anything of the
above!
> In your design, if the messages are heavyweight, you could have multiple
> consumer threads waiting on the same socket events and process them
> immediately. However, I wouldn't recommend adding threads if you don't need
> them.
If I'm successful, the message system will be used quite heavily,
potentially in the range of tens of thousands of messages being
processed per second on the server side. But for now, a single worker
thread design will be just fine. It's better to have something working
first.
Thanks a lot for the encouraging information. It's time for some
implementation now...
> I pity the fool that uses select().
:-)
> Cheers,
> M
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10 (Darwin)
>
> iEYEARECAAYFAknaXbYACgkQqVAj6JpR7t6AugCffFzkZHLIv8tkL9dSPPY/W1Cn
> qesAnjvSt6VYnyKeeSN65d4gA94c4ikw
> =csm1
> -----END PGP SIGNATURE-----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden