From: grahn+nntp@snipabacken.se   
      
   Possibly a stupid questions, and I admit I haven't thought it through.   
      
   Would the following make sense?   
      
   Assume I do logging, similar to Unix syslog logging, over a TCP   
   socket. The protocol is just a unidirectional stream of   
   CRLF-terminated lines of text. Losing some of the lines is OK (and   
   even desireable, when some error causes a storm of log messages) but   
   losing parts of a line is not.   
      
   And I do it like this on the client side:   
      
   - create a TCP socket, set it non-blocking   
   - logging the first line means a simple write() to the socket. If that   
     works, fine. If I get a short count, I store the remainder of the string   
     for the future.   
   - if I'm supposed to log another line, I try to write this remainder   
     first. If that still doesn't work, I discard the new log line.   
      
   Seems to me this would be a simple way to implement a non-blocking   
   logging call. The current implementation I want to replace uses an   
   extra level of indirection: log messages are queued to a thread which   
   writes (blocking) to the socket. Thus it needs to implement its own   
   mechanism for limiting the logging rate/dropping log messages.   
      
   If it *does* make sense, what are the drawbacks?  I can think of two:   
      
   - A partial log line doesn't get finished until the next time   
     the client tries to log something -- maybe hours later.   
      
   - If the server is naively written to read a complete line, it may   
     be blocked for hours waiting for such a remainder. On the other   
     hand, such a server would block forever anyway, if the client host   
     disappeared from the network in the middle of a log line.   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)