fjpanag commented on issue #3157:
URL: 
https://github.com/apache/incubator-nuttx/issues/3157#issuecomment-805943262


   I had a look at this discussion. Thank you.
   
   Some comments:  
   
   I agree that syslog should not affect the real-time performance of the 
system in any way.  
   That is:
   - It must not lock the scheduler, or affect higher priority threads in any 
way.
   - It must not lock interrupts, or cause any delays in their execution.
   - It must not cause any dead-locks in case priority inversion is not 
possible.
   
   On the other hand, I do not see the problem using a mutex-like object.  
   Syslog is a resource, that is shared between multiple tasks. Of course it 
has to be locked to ensure thread-safety.  
   An of course this means that one thread may lock another thread. But this is 
expected. This is what happens every time that a common resource is shared 
between tasks (e.g. I2C bus, used by multiple tasks). It is up to the 
programmer to ensure that such kind of locking will not harm their application, 
and that the induced jitter is acceptable.  
   
   Nevertheless, it is the expected behavior. Knowing nothing about a new OS, I 
would directly assume that a using the same resource in multiple places will 
cause jitter. I wouldn't even bother look up any documentation to confirm this.
   
   Regarding buffering, I would say that it seems like a good idea.  
   As mentioned in the above thread, it also enhances performance which is 
great.  
   But:
   - If this is the solution to this problem, then it has to become the 
standard, and remove the non-buffered output.
   - As discussed in #3050, currently the syslog buffering is broken. It is not 
flushed atomically, if the printed message is larger than the IOB size.
   - Buffering of course has its own problems too. It needs RAM, it limits the 
maximum size of the message etc etc...
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to