Date: Wed, 17 Feb 1999 06:58:53 -0500 (EST) From: Howard Goldstein <hgoldste@mpcs.com> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-hackers@freebsd.org Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <14026.44797.255019.909901@penny.south.mpcs.com> In-Reply-To: <199902140105.SAA01804@usr06.primenet.com> References: <14021.27462.556760.465144@penny.south.mpcs.com> <199902140105.SAA01804@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > > > 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. Agreed. However, implemented as a library, will I be able to claim performance? A very quick dejanews scan seems to hint that libraries are not an uncontroversial place for them to reside in. > 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. (Forced timeslice donation below) SMP changes things a lot, doesn't it... Nice part is there's a lot of new trail to blaze. Kind of starting to feel like around 20 years ago, minus Reagan and Blondie. > '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. A call that blocks can be a good thing. It all depends on what you're trying to accomplish, whether those other processes eating up cycles are also your processes or someone you don't really care about too much. Awaiting i/o, or expiration of a timer, these things seem like they could be more efficiently resolved in the kernel during blocking calls, at least when those other processes are mine! POSIX-like [*] realtime signals managed by the kernel potentially eliminate the userland dispatching stuff, resulting in even more joyful blocking. Granted, one man's dread is another man's joy... [*] it isn't so much conformance to a doc as it is the functionality that I sought, and nb., that was fallback functionality. If I have a modified time value in a modified select() I'll slink away from this. > 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! I haven't reviewed that thread at any length; I'll try this weekend. It seems every significant packet switching project I've ever worked on we've either rolled our own non-preemptive executive (sans threads) or used something near-off-shelf (Hagar in a mostly X.25 switch comes to mind). I'm not sure a comparison is valid give the limited scope of what the o/s in a switch has to deal with compared to the more generic kinds of things we have to serve up in FreeBSD. 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?14026.44797.255019.909901>