On Mon, 25 Nov 2002 22:14:43 +0100 (CET) <segv-tomate freesurf fr> wrote:
maybe i don't use threads very well... so, in my program, i have to fork to execute a program which will write into a pipe that the father will read into. for that, i have a function that creat a new thread like that: g_thread_create((GThreadFunc) toolbar_start_OS_thread, data, 0, &error);
Fork/execing a program is a very different thing from creating a thread! And IMHO it is less error-prone to start a different program than it is to start a thread. Programs do not share their memory, threads do. So when you are using threads you have to protect lots of data items with locks etc. If you don't get this right, you might get bugs that are very difficult to track down. There was an interesting article about threads recently on Kuro5hin: http://www.kuro5hin.org/story/2002/11/18/22112/860 An alternative to using threads would be to spawn a different program with g_spawn_async_with_pipes, create a GIOchannel with g_io_channel_unix_new and add a watch for new data with g_io_add_watch. Now a callback is called e.g. every time some new data arrives from the other program, and can react to that without disturbing the event flow of your GUI. It has the added benefit of being able to test the program that you spawn separately. Usually threads or separate programs are used to perform tasks that take too long to do in a callback. An alternative approach would be to divide the tasks in little chucks that you carry out in a timeout or idle function. This means rewriting the task, but it fits in with the event-driven model of GTK+ programs and is easier than spawning separate programs or using treads, I think. Roland -- R.F. Smith /"\ ASCII Ribbon Campaign r s m i t h @ x s 4 a l l . n l \ / No HTML/RTF in email http://www.xs4all.nl/~rsmith/ X No Word docs in email / \ Respect for open standards
Attachment:
pgpqsKuFUVFhA.pgp
Description: PGP signature