site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=1w0NHlQBk3NMxa039yXYB9/lVwn/XUcS8s3forDCePU=; b=A/VB03fpFlyNWhhYXz062rpHCPir37sTsibDQmzIkr7AOjV5dECtgxNpGkCx++oN/F wU2BUljDS/FY/tmdRhxP0i5ejsB9wlxGUxu7JaZMkeNOEG3U2b8KYyfREodeS6JJMYLO jpVArE+ym2Brz2WXdQxjd79t2KDlmN5PO/SFI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RLyxGD83Gkjolt3qMZE9qgb6k+dDNzLo/CaHxQMo0Ir1qE3Gujg6WMOJ5Kb999C5Vp jvWl9xauOThgJXAP6+1JhzAMQNC5LuekGlIUreUlwr23hDTlKz2qYUQSun4yNcVoI7Ej KD/Mi81uxZy5s7whHeVcln8jB4pg9YdpEsXvE= 2009/4/6 A.M. <agentm@themactionfaction.com>:
-----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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com