Andi Kleen wrote:
> processes (PTHREAD_SCOPE_SYSTEM). The previous comment about slapd > only needing to yield within a single process is inaccurate; since > we allow slapcat to run concurrently with slapd (to allow hot > backups) we need BerkeleyDB's locking/yield functions to work in > System scope.
That's broken by design - it means you can be arbitarily starved by other processes running in parallel. You are basically assuming your application is the only thing running on the system which is wrong. Also there are enough synchronization primitives that can synchronize multiple processes without making such broken assumptions.
Again, I think you overstate the problem. "Arbitrarily starved by other processes" implies that the process scheduler will do a poor job and will allow the slapd process to be starved. We do not assume we're the only app on the system, we just assume that eventually we will get the CPU back. If that's not a valid assumption, then there is something wrong with the underlying system environment.
Something you ought to keep in mind - correctness and compliance are well and good, but worthless if the end result isn't useful. Windows NT has a POSIX-compliant subsystem but it is utterly useless. That's what you wind up with when all you do is conform to the letter of the spec.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
