how can a GTK application deal with real-time serial port input?

[Eric Smith <eric brouhaha com>]

I'm working on a program that will monitor a data stream being received on a
serial port (or tcp socket), process the data, and update a display.  Some of
the data must be processed within milliseconds of being received, but in
general there can be delays of nearly a second between transfers.

I've gotten to the point where I can display some static data in the manner I
want, but I haven't figured out how to make the program listen to the serial
port after gtk_main() is called.

I suppose I could make the program multithreaded, although I was hoping to
avoid that because it will be less portable.  But it's not clear how I can
send a gtk event from my serial listener thread to the thread running
gtk_main().

I could fork another process (which is more portable than threads), and have
them communicate via shared memory (not as portable), but I still don't know
how to get one process to send a gtk event to the other.  If I have one
process send a unix signal to the other, is it safe to call gtk_widget_draw()
from a unix signal handler?  I worry that the unix signal might interrupt
something non-reentrant in gtk.

Ordinarily in non-GTK programming, this type of problem is solved using
select().  But I can't use that while my program is in gtk_main().  I've
looked at the source for gtk_main(), but I don't yet have a very complete
grasp of what's going on.  But would it be reasonable to hack a non-iterative
version of gtk_main(), and call it in a loop, i.e.,

	gtk_main_start ();  /* hypothetical function */
	for (;;)
	  {
	    i = select (..., timeout);
            ...
	    gtk_main_inner ();  /* hypothetical function that doesn't loop */
          }
	gtk_main_finish ();  /* hypothetical function */

That approach would have the drawback of not being able to process
new data while gtk is doing stuff, and while that's not terribly great,
I think I could live with it.

I could perhaps use asynchronous I/O by setting a signal handler
for SIGIO, but I'm not certain how portable that is.  In fact, I've never
tried it under Linux.  However, if it works, this would give priority to
processing the incoming data, which would be good.

The other option, I suppose, is to use gtk timeouts.  I'm reluctant to do
that because I wouldn't want to set a timeout of less than ten milliseconds
then use up a huge amount of CPU polling the serial port.

Or is there some other clever way to do this that I've overlooked?  Any
suggestions will be appreciated.

Thanks!
Eric