Date: Sun, 14 Feb 1999 01:05:30 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: hgoldste@bbs.mpcs.com Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902140105.SAA01804@usr06.primenet.com> In-Reply-To: <14021.27462.556760.465144@penny.south.mpcs.com> from "Howard Goldstein" at Feb 13, 99 07:08:38 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Realtime signals would help almost as much, perhaps in a more portable > > > way. > > > > man setitimer > > 'Sir, may I please have some more?' > > I use it...I always feel dirty when I have setitimer signal a clumsy > monolith that is itself in many ways like the one that deals with the > aftermath of a select(). More timers, a la posix realtime signals > (p1003B? I'm sure I'm citing the wrong posix id) would be cleaner, > and would make it easier to write pthreaded applications. Silly Oliver Twist... POSIX is getting more and more barnacle encrusted as time goes on. The POSIX stuff is to the point now that it should be implemented in libraries, instead of kernels, so that the majority of it can be ignored, while still allowing you to claim conformance. My personal preference for high concurrency, low overhead, SMP scalable threads is a user space scheduler that consumes async call gates. POSIX chickened out on this, and there are still calls that you can make that force you to give away your quantum, and which have no async alternatives. 'Some calls are more async than others.' >From my point of view, if the scheduler gives me a quantum, then *it's MY quantum*, and anything that makes me "give part of it back" for the dubious benefit of making a blocking call and taking a full context switch is just plain stupid. See the other thread in this forum on FreeBSD vs. Network Appliance market niches. NetApp uses a non-preemptive multitasking and multithreaded kernel. This is good, because it eliminates context switch thrashing. This is bad, because it's not SMP scalable, and, like Windows 3.1, you have to trust all of your threads of execution to "play nice". An async call gate, combined with a user space scheduler, resolves the context switch thrashing equally well, while still allowing the SMP scalability, and taking into account that God can't write all of your threads of execution at the cost of minimally necessary context switch overhead. Whee! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902140105.SAA01804>