Eric Cooper wrote:

 >> That's how it was originally. But if you look again at my code, you 
can see that the version with Unix.O_NONBLOCK is commented out. That's 
because on one of my machines (the one with a newer version of GTK and 
LablGTK, I believe), I got exceptions every time the program tried to 
read the input.
 >
 > Right, me too.  I use code like this to read from the channel inside
 > the watcher:
 >
 > let try_read chan ~buf ~pos ~len =
 >   try Some (Glib.Io.read chan ~buf ~pos ~len)
 >   with Glib.GError "g_io_channel_read: G_IO_ERROR_AGAIN" -> None

Thanks for the tip. This does indeed eliminate the errors with a 
non-blocking channel. But I still get excessive CPU usage. I have also 
tried setting the priority on add_watch (both `DEFAULT_IDLE and `LOW). 
Nothing seems to make any difference. It's true that my app does allow 
other programs to grab a significant amount of CPU time when they need 
it. But when my app is idle and not much else is running, 'top' shows it 
using over 90% of the CPU. That's certainly not normal, and I would 
think very undesirable.

A 'sleep' call might help, but the standard Unix.sleep only accepts 
1-second increments, which is undesirable. But I can try a wrapper for 
usleep() ... unless someone has a better idea.

-- 
Matt Gushee
: Bantam - lightweight file manager : matt.gushee.net/software/bantam/ :
: RASCL's A Simple Configuration Language :     matt.gushee.net/rascl/ :