2011/2/18 erik quanstrom <quans...@labs.coraid.com>: >> I know we're fond of bashing people who need to eek performance out of >> systems, and a lot of time it's all in good fun. There's little >> justification for getpid, but getpid isn't the only implementor of >> this functionality. For other interfaces, it definitely makes sense to >> speed up the system to speed up applications. Argue about it all you >> want, but without this sort of mentality, we also wouldn't have >> non-blocking I/O or kernel thread support. > > define "we". there's no non-blocking io in plan 9.
I didn't mean "we" in the context of Plan 9. I meant "we" in the context of computer science and software engineering. Someone thought there was a problem with an interface and came up with a solution. Plan 9 has a different approach to solving the problem by providing a different means to addressing it entirely. Arguing that performance is unimportant is counterintuitive. It certainly is. Arguing that it is unimportant if it causes unnecessary complexity has merit. Defining when things become "unnecessarily complex" is important to the argument. Applications with timers (or doing lots of logging) using gettimeofday(2) being instantaneously improved by *very* measurable amounts due to such changes seems like a good idea to me, and it doesn't seem too complex. Doing it for getpid(2) seems pretty dumb. I think it's time that we do some real-world style benchmarks on multiple systems for Plan 9 versus other systems. I'd be interested in seeing what we could come up with, how we address it, and the relative "ease" for each solution. Anybody want to work together to put something like that together? --dho > - erik > >
