On Thu, 2007-02-01 at 00:22 +0200, Constantine Kousoulos wrote: > > It's nice to know the direction the implementation is headed. I > would be grateful if you could supply links that further document > the above mentioned statement. To be honest, i had the exactly > opposite idea since it has been mentioned that the Coyotos kernel > was a candidate to replace the Mach kernel and Coyotos has an > asynchronous design.
If we rely on asynchronous messaging, then we are stuck when a synchronous system comes around. If we rely on RPC, then asynchronous systems (like Mach and Coyote) implement RPC, and do so as a major efficiency priority. > > Regarding the syslog problem, what can be done? From what has been > said so far, the intermediate translator solution is not optimal. > Do we use syslog as it is but carefully because of the internal > locking? If so, this task should be deleted. In my opinion, we should use syslog() as it is, and the work necessary is to make sure that the servers which get invoked in the course of processing a syslog() call do the right thing. As I said, this is really only an issue at bootstrapping time and for non-multi-threaded servers; and that every server should be careful to call syslog only outside locks. Even using asynch messages in Mach would not necessarily be sufficient to avoid the deadlock problem; note that asynch sends in Mach normally block if the recipient's message queue is filled. > How about this: what if the syslog daemon was rewritten as a > syslog translator capable of handling the locking issue? I don't see what that means; the point is that things like syslog shouldn't be called within critical sections, and that if one has avoided that, normal multi-threaded servers should have no trouble using syslog(). If they *do* have such trouble, then this needs to be sorted out.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
