>> From: Ricardo Lebre <[EMAIL PROTECTED]> >> >> I'm developing a multithreaded server application using gtk+-1.2 and real >> time is a critical factor.
I've done the same thing for audio for the last several years, where "real time" doesn't mean "real fast", it means "real time" (ardour.sf.net). I can assure you that GTK+ will not get in your way. You need to design your program correctly, and your description of what your threads do suggests that you have already made the first and most basic error: planning to have several different threads operating on the GUI. Most of the thread issues that relate to GTK+ are made much simpler by having only a single thread issue any and all calls to GTK+/GDK/glib/Xlib functions. Add an internal pipe (created with pipe(2)), connect it with gtk_input_add() or its cousins in glib, and have other threads send "requests" to the GUI thread over it. the callback for the pipe in the GUI thread reads the requests and executes them. Ron wrote: >You might be better off adding sources to the mainloop. >Add a poll on your listening socket. In the callback for that poll, >add a poll on each newly created connection. For a server application, this is probably a poor idea. Fast response to I/O conditions on additional fd's is not going to happen from the GUI main loop. Any work being done by other GUI-related callbacks will delay a response to new input on some server-related file descriptor. On the other hand, most people generally prefer to have server programs be able to operate without a GUI, and have them provide a control protocol that can be used by a standalone GUI/text-UI program, possibly even remotely. --p _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
