Re: Multithreaded server
- From: Paul Davis <pbd op net>
- To: rsteinke w-link net
- Cc: riclebre gsd inesc-id pt, gtk-list gnome org
- Subject: Re: Multithreaded server
- Date: Tue, 30 Jul 2002 06:22:51 -0400
>> From: Ricardo Lebre <riclebre gsd inesc-id pt>
>>
>> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]