> From: Ricardo Lebre <[EMAIL PROTECTED]> > > I'm developing a multithreaded server application using gtk+-1.2 and real > time is a critical factor. > > On my application the main thread (A) launches thread (B) that initializes > a gtk console and blocks itself at gtk_main(). After that, thread (A) > blocks itself waiting for socket connections (with accept system call). > When a new connection is received, it launches a new thread (C) for > handling requests pending at the the newly created socket. Thread (C) > then has to update the gtk console.
There may be a problem with this. Generally, all the gui-related activity has to take place in a single thread. > - Because all threads execute concurrently i'm beleive i'm having a > conflict between thread (B) and thread (C) is it possible? > > - Is there any other way around for doing this? 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. In reality, the heart of the gtk+ (really glib) mainloop is one big call to select(). By creating polls on each of the sockets you're interested in, you allow the application to block inside select() until one of them recieves data. The mainloop will then check which sockets are pending, and call the callbacks for the appropriate polls. > - I was thinking in using gdk_input_add but as far as i can tell > subsequent calls to the callback function are handled sequentially (no > thread is created to handle the request) and thus is not applied on my > situation, is this correct? There's probably no reason why this sort of handling would be a problem in your application, unless you're dealing with some case where one callback needs to block until another is finished. Even then, it's probably easier to create an idle callback to handle the case you need to delay. Ron Steinke _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
