Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
From: bert hubert
Date: Mon Feb 05 2007 - 17:08:08 EST
On Mon, Feb 05, 2007 at 01:57:15PM -0800, Linus Torvalds wrote:
> I doubt very many people want to do that. It would tend to simply be nicer
> to do
>
> async(poll);
Yeah - I saw that technique being mentioned later on in the thread, and it
would work, I think.
To make up for the waste of time, some other news. I asked Matt Dillon of
DragonflyBSD why he removed asynchronous system calls from his OS, and he
told me it was because of the problems he had implementing them in the
kernel:
There were two basic problems: First, it added a lot of overhead when
most system calls are either non-blocking anyway (like getpid()).
Second and more importantly it was very, very difficult to recode the
system calls that COULD block to actually be asynchronous in the kernel.
I spent some time recoding nanosleep() to operate asynchronously and it
was a huge mess.
Aside from that, they did not discover any skeletons hidden in the closet,
although from mailing list traffic, I gather the asynchronous system calls
didn't see a lot of use. If I understand it correctly, for a number of years
they emulated asynchronous system calls using threads.
We'd be sidestepping the need to update all syscalls via 'fibrils' of
course.
> If you think of it in those terms, it all makes sense *without* any file
> descriptors what-so-ever, and the "wait_for_async()" interface also makes
> a ton of sense (it really *is* "waitpid()" for the system call).
It has me excited in any case. Once anything even remotely testable appears
(Zach tells me not to try the current code), I'll work it into MTasker
(http://ds9a.nl/mtasker) and make it power a nameserver that does async i/o,
for use with very very large zones that aren't preloaded.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/