dbus-monitor and control-c (again)

[Randell Jesup]

Perhaps already fixed in CVS/git/etc: dbus-monitor and control-c

a) dbus-monitor doesn't actually respond to ^C.  It has a signal
   handler, but it doesn't work in a "quiet" system - you have to ^Z out
   and kill it.  The problem is that
   dbus_connection_read_write_dispatch() is used with -1 (blocking), so
   ^C will invoke the signal handler, but won't kick you out of the 
   blocking function call, and so it won't exit.

   Patch: change -1 to (say) 1000, and then it will wait no more than 1
   second before noticing the ^C.

b) (related): profile mode doesn't fflush() at the end of each message,
   so if you have to kill it the output gets lost, and if you're piped
   to a tee (for example), you won't see output for a while unless
   there's a lot of traffic.

   compare: "dbus-monitor --profile" to "dbus-monitor --profile | tee /tmp/foo"

   Patch: add fflush() at the bottom of print_message_profile()

   Note that adding it to the main loop right before exit() doesn't seem
   to help, because unless you use "-i" to tee, ^C will cause tee to
   exit before dbus-monitor gets a chance to flush.  This issue with tee
   may also be why someone was reporting losing output on ^C in the
   first place: --monitor mode uses fflush() already, so there's no need
   for a signal handler for it - data will never be buffered for more
   than one dbus message.

Overall suggestion: ditch the ^C handler and add fflush() to
print_message_profile().  Alternate: change timeout to 500 or 1000, and
add fflush() to print_message_profile().

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
rjesup at wgate.com