[Openais] Re: Bug 171 idea

Steven Dake sdake at mvista.com
Wed Oct 27 11:17:49 PDT 2004


I think your right stderr and file output could also block...  

What we should do is use the poll abstraction to determine if the file
descriptor can be written (stderr, syslog, the file descriptor) and if
it can be written, flush one log message.  If all messages have been
flushed, remove the write bit for the logging file descriptors.  If not,
continue in the poll loop flushing log messages as possible.  Keep
logging fds at lowest priority as compared to the token receive file

I'd like to sort out some of these gmi bugs though before I get into
this feature.  If you want to look at it and need any help let me know


On Wed, 2004-10-27 at 10:57, Mark Haverkamp wrote:
> On Wed, 2004-10-27 at 10:40 -0700, Mark Haverkamp wrote:
> > On Wed, 2004-10-27 at 10:33 -0700, Steven Dake wrote:
> > > Mark
> > > 
> > > The retry is ok but the nanosleep is troublesome.  sys_nanosleep I
> > > believe uses the standard clock to sleep (which has 1 ms resolution). 
> > > This can be a real problem for performance.  Also openais services
> > > should be completely nonblocking in all respects..  Blocking with
> > > nanosleep is wrong..
> > > 
> > > Could you try a retry patch without the nanosleep?
> > 
> > I'll try something else.  But, I'm sure that output to a file and to
> > stderr has the possibility of blocking.
> > 
> > Mark.
> Maybe this can be solved with your idea of queueing messages as you
> mentioned on the comments on bugs 145 and 168.
> Mark.

More information about the Openais mailing list