Re: Using fork() in a GTK C/Vala application
On Wed, 2 Sep 2015 10:50:43 +0200 Gian Mario Tagliaretti wrote: > On 2 September 2015 at 05:33, Jim Charlton wrote: > > Hi Jim, > > > I have had similar problems and ended up using > > g_spawn_async_with_pipes() with a separate binary. This works well > > for me as I often need to launch several instances of this "thread". > > g_spawn_async_* have the (personally unwanted) behavior on windows to > open a console for each process [1], which is quite horrible for the > user. > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=509201 If you have glib >= 2.40, try GSubProcess. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using fork() in a GTK C/Vala application
On 2 September 2015 at 05:33, Jim Charlton wrote: Hi Jim, > I have had similar problems and ended up using g_spawn_async_with_pipes() > with a separate binary. This works well for me as I often need to launch > several instances of this "thread". g_spawn_async_* have the (personally unwanted) behavior on windows to open a console for each process [1], which is quite horrible for the user. [1] https://bugzilla.gnome.org/show_bug.cgi?id=509201 Cheers -- Gian Mario Tagliaretti GNOME Foundation member gia...@gnome.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using fork() in a GTK C/Vala application
On 15-09-01 07:27 AM, rastersoft wrote: In fact, I'm already using pipes and more; I can just replace the Thread call with a fork() and everything will work fine. The only idea I see I can use is to physically separate both process in different binaries and use named pipes... On 01/09/15 16:05, Chris Vine wrote: On Tue, 1 Sep 2015 15:33:19 +0200 rastersoft wrote: Thanks for your answer. Unfortunately, I'm running out of options: currently I'm using threads, but there is a nasty bug that makes my program crash sometimes. It is very subtle, because it hapens usually after being running for two-three days. It is a double free. I tried with Valgrind, but when I use it, the error doesn't trigger, which makes me suspect it is a race condition between both threads (valgrind ensures that only one thread runs each time). I checked all the code, and isolated everything as much as I could, and adding as many locks as I could imagine, trying to remove that bug, but its imposible, so I decided to separate the code in two independent processes to be able to use valgrind and finally find what is happening. But as you say, it seems I'll have to do something else... Can you fork() before you launch any new threads or call any gio/gtk+ functions, and then perhaps communicate using pipes? That should be safe. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list I have had similar problems and ended up using g_spawn_async_with_pipes() with a separate binary. This works well for me as I often need to launch several instances of this "thread". jim... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using fork() in a GTK C/Vala application
On Tue, Sep 1, 2015 at 10:33 AM, rastersoft wrote: > It is very subtle, because it hapens usually > after being running for two-three days. It is a double free. I tried > with Valgrind, but when I use it, the error doesn't trigger, which makes > me suspect it is a race condition between both threads (valgrind ensures > that only one thread runs each time). > Maybe you could try giving Thread Sanitizer and/or Address Sanitizer a go. They're available in recent-ish versions of gcc and clang; just rebuild your program with CFLAGS and LDFLAGS "-fsanitize=thread" or "-fsanitize=address". When bad things happen, messages will be printed to the console and your program aborted. -- Leandro ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using fork() in a GTK C/Vala application
In fact, I'm already using pipes and more; I can just replace the Thread call with a fork() and everything will work fine. The only idea I see I can use is to physically separate both process in different binaries and use named pipes... On 01/09/15 16:05, Chris Vine wrote: > On Tue, 1 Sep 2015 15:33:19 +0200 > rastersoft wrote: >> Thanks for your answer. Unfortunately, I'm running out of options: >> currently I'm using threads, but there is a nasty bug that makes my >> program crash sometimes. It is very subtle, because it hapens usually >> after being running for two-three days. It is a double free. I tried >> with Valgrind, but when I use it, the error doesn't trigger, which >> makes me suspect it is a race condition between both threads >> (valgrind ensures that only one thread runs each time). I checked all >> the code, and isolated everything as much as I could, and adding as >> many locks as I could imagine, trying to remove that bug, but its >> imposible, so I decided to separate the code in two independent >> processes to be able to use valgrind and finally find what is >> happening. But as you say, it seems I'll have to do something else... > Can you fork() before you launch any new threads or call any gio/gtk+ > functions, and then perhaps communicate using pipes? That should be > safe. > > Chris > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using fork() in a GTK C/Vala application
On Tue, 1 Sep 2015 15:33:19 +0200 rastersoft wrote: > Thanks for your answer. Unfortunately, I'm running out of options: > currently I'm using threads, but there is a nasty bug that makes my > program crash sometimes. It is very subtle, because it hapens usually > after being running for two-three days. It is a double free. I tried > with Valgrind, but when I use it, the error doesn't trigger, which > makes me suspect it is a race condition between both threads > (valgrind ensures that only one thread runs each time). I checked all > the code, and isolated everything as much as I could, and adding as > many locks as I could imagine, trying to remove that bug, but its > imposible, so I decided to separate the code in two independent > processes to be able to use valgrind and finally find what is > happening. But as you say, it seems I'll have to do something else... Can you fork() before you launch any new threads or call any gio/gtk+ functions, and then perhaps communicate using pipes? That should be safe. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using fork() in a GTK C/Vala application
Thanks for your answer. Unfortunately, I'm running out of options: currently I'm using threads, but there is a nasty bug that makes my program crash sometimes. It is very subtle, because it hapens usually after being running for two-three days. It is a double free. I tried with Valgrind, but when I use it, the error doesn't trigger, which makes me suspect it is a race condition between both threads (valgrind ensures that only one thread runs each time). I checked all the code, and isolated everything as much as I could, and adding as many locks as I could imagine, trying to remove that bug, but its imposible, so I decided to separate the code in two independent processes to be able to use valgrind and finally find what is happening. But as you say, it seems I'll have to do something else... On 01/09/15 15:12, Chris Vine wrote: > On Tue, 1 Sep 2015 13:54:34 +0200 > rastersoft wrote: >> Hi all: >> >> I'm working on a project which, for several reasons, will use the >> Posix fork() call. The question is: if I have an active GTK main loop >> in the program before calling fork(), is there something I have to do >> after calling it in the child process? I know that I must NOT use Gtk >> calls in the child, but should I quit the main loop in the child? >> Should I quit before the Gtk main loop, create the child, and call it >> again? What can I do to don't loose registered callbacks and so on? > Because of gio, which uses background threads for some of its stuff > (in particular for its async i/o operations) all GTK+ programs are in > effect multi-threaded nowadays. This makes calling fork() problematic, > because as you probably know POSIX only permits async-signal-safe > functions to be called after a fork() and before an exec() in a > multi-threaded program. If you want to do anything other than a fork() > and an exec(), then start a thread not a new process. This leaves your > question redundant. > > For asynchronous tasks you might want to look at GTask (available from > glib-2.36). For an encapsulation of the fork()/exec() approach, see > also GSubProcess, available from glib-2.40. > > Chris > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using fork() in a GTK C/Vala application
On Tue, 1 Sep 2015 13:54:34 +0200 rastersoft wrote: > Hi all: > > I'm working on a project which, for several reasons, will use the > Posix fork() call. The question is: if I have an active GTK main loop > in the program before calling fork(), is there something I have to do > after calling it in the child process? I know that I must NOT use Gtk > calls in the child, but should I quit the main loop in the child? > Should I quit before the Gtk main loop, create the child, and call it > again? What can I do to don't loose registered callbacks and so on? Because of gio, which uses background threads for some of its stuff (in particular for its async i/o operations) all GTK+ programs are in effect multi-threaded nowadays. This makes calling fork() problematic, because as you probably know POSIX only permits async-signal-safe functions to be called after a fork() and before an exec() in a multi-threaded program. If you want to do anything other than a fork() and an exec(), then start a thread not a new process. This leaves your question redundant. For asynchronous tasks you might want to look at GTask (available from glib-2.36). For an encapsulation of the fork()/exec() approach, see also GSubProcess, available from glib-2.40. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
