Date: Tue, 2 Dec 1997 18:48:54 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dyson@freebsd.org (John S. Dyson) Cc: tlambert@primenet.com, toor@dyson.iquest.net, current@freebsd.org Subject: Re: FYI: usage of new AIO calls Message-ID: <199712021848.LAA18076@usr04.primenet.com> In-Reply-To: <3483B288.DD0CD0E9@freebsd.org> from "John S. Dyson" at Dec 2, 97 07:02:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> BTW, I also plan to implement pread/pwrite, but haven't decided to > implement as a kernel call, or as a section (3) subroutine. (Those > are less of an issue though.) I don't think you can implement pread/pwrite as section (3) routines; the need for them arises from the need to pass a seek offset with a read or write request because you can't trust the seek+read or seek+write to be atomic -- so implementing them that way would leave a race window open. > So, the point that I am trying to make, is that I am implementing > system calls or subroutines with the attempt of meeting *BOTH* POSIX > and UNIX when applicable, and the aio_* routines do that. We am missing > a minor amount of functionality in our implementation right now, but am > too busy to do that right now. The code WILL be in 3.0, and will be > in -current very soon. (aio_fsync, and some aio_cancel functionality). I know that; it's just evil that the POSIX people have implemented before thinking. SVR4 kernel threading was implemented without a great deal of thinking (the SVR4 VM architect assured me that there was VM support for dynamic per thread stacks, but that the SVR4 threading implementation simply chose to ignore it in favor of statically allocated stacks; similar cases abound). I hate the fact that it's still possible to make a non-I/O based blocking call (like, oh, wait3()) that doesn't result in a call conversion and context switch: basically, you *must* give away your quantum that you were promised by the scheduler in order to make this and similar calls. What were they thinking? > Likewise, my scaffolding for threads will support pthreads. Which > version? Probably the most recent. (Hopefully, someone else will > implement most of the threading package though.) We could support > Solaris or Linux threads, but again (IMO), that should be in the > form of a reverse or backwards compatibility package. Agreed; the Solaris threading model is inherently flawed; it results in "churning" of scheduling contexts, and there's no "thread group" affinity to alleviate even some of the work that has to be done while that's happening. It also frequently results in CPU starvation when the number of user space threads outnumber the kernel threads to which they are coupled. And the Solaris model and SVR4 model are pretty much identical in this behaviour. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712021848.LAA18076>