Re: [task #5490] syslog

[Thomas Bushnell BSG]

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