Re: Pointers and spawning processes with glib
On Fri, 10 Dec 2010 13:01:50 +1100 Lex wrote: It is pretty obvious it must be copied, even on windows where fork/exec doesn't exist. It's pretty obvious if: 1) you understand how processes work and differ from threads and... 2) you like to think about how things work under the hood For a lot of users, like Rupert, it's not at all obvious. I don't think adding a note in the documentation is too much effort, and would be of some benefit. Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Pointers and spawning processes with glib
On 10 December 2010 19:02, Robert Pearce r...@bdt-home.demon.co.uk wrote: On Fri, 10 Dec 2010 13:01:50 +1100 Lex wrote: It is pretty obvious it must be copied, even on windows where fork/exec doesn't exist. It's pretty obvious if: 1) you understand how processes work and differ from threads and... 2) you like to think about how things work under the hood For a lot of users, like Rupert, it's not at all obvious. I don't think adding a note in the documentation is too much effort, and would be of some benefit. I am not criticising Rupert, he's been reading the code, good, but he didn't go far enough, fork/exec is well explained in many books and Google-able documents, starting with Wikipedia. The Glib reference documentation is not intended to be an introduction to any topic. Programmers should not expect to use just a reference manual if they do not understand the concepts behind it. So if a programmer doesn't know anything about processes, hashes, URIs or any of the other concepts handled in Glib( or windowed graphics topics in GTK+) they should look at the introductory material available elsewhere. The reference manual would become too big and unwieldy if it tried to be a conceptual introduction to all its topics as well. Don't get me wrong, I think that the GLib/GTK+ documentation has lots of problems, but this isn't one of them. Cheers Lex Cheers, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Pointers and spawning processes with glib
Lex Trotman ele...@gmail.com writes: On 10 December 2010 19:02, Robert Pearce r...@bdt-home.demon.co.uk wrote: On Fri, 10 Dec 2010 13:01:50 +1100 Lex wrote: It is pretty obvious it must be copied, even on windows where fork/exec doesn't exist. It's pretty obvious if: 1) you understand how processes work and differ from threads and... 2) you like to think about how things work under the hood For a lot of users, like Rupert, it's not at all obvious. I don't think adding a note in the documentation is too much effort, and would be of some benefit. I am not criticising Rupert, he's been reading the code, good, but he didn't go far enough, fork/exec is well explained in many books and Google-able documents, starting with Wikipedia. The Glib reference documentation is not intended to be an introduction to any topic. Programmers should not expect to use just a reference manual if they do not understand the concepts behind it. So if a programmer doesn't know anything about processes, hashes, URIs or any of the other concepts handled in Glib( or windowed graphics topics in GTK+) they should look at the introductory material available elsewhere. The reference manual would become too big and unwieldy if it tried to be a conceptual introduction to all its topics as well. Don't get me wrong, I think that the GLib/GTK+ documentation has lots of problems, but this isn't one of them. Ok, so naturally I don't think I'm stupid :-) More to the point, I don't think that I was being lazy. By the time I sent that email, I was absolutely certain that the memory was copied (I'd even read about how copy-on-write semantics makes copying everything not utterly crazy). But, since this was the first post I've made to this list, I wanted to make sure that I didn't start with The following change should be made to the documentation when there was the slightest glimmer of a chance I might have been wrong about what was going on. Right. Now about knowing about processes. In hindsight, yes, once the other process is running, it can't possibly talk about the same memory (without some sort of clever shared memory thing going, which isn't the point of this discussion). However, I was worried that maybe there was some handler, maybe called on exit of the child process or something, which would read the memory at the address I'd passed to the function earlier. I don't *think* this is a completely crazy thing to wonder about. Looking at the code for the implementation, I see that there isn't. But surely one should be able to use a library without reading the implementation to work out how? Indeed, most APIs (intend to) document what they do for pointer arguments which look like there's some chance they might be retained. We'll take control of this memory. Don't free it for example. Anyway, this was meant to be a quick question, not the start of a flame war, so I'll shut up now. Thank you both very much for the responses. Rupert pgpV6aNeuCkIO.pgp Description: PGP signature ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Pointers and spawning processes with glib
The Glib reference documentation is not intended to be an introduction to any topic. Programmers should not expect to use just a reference manual if they do not understand the concepts behind it. So if a programmer doesn't know anything about processes, hashes, URIs or any of the other concepts handled in Glib( or windowed graphics topics in GTK+) they should look at the introductory material available elsewhere. The reference manual would become too big and unwieldy if it tried to be a conceptual introduction to all its topics as well. But perhaps a short note with a link wouldn't make it too big? Don't get me wrong, I think that the GLib/GTK+ documentation has lots of problems, but this isn't one of them. Cheers Lex -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Pointers and spawning processes with glib
Hi,
I'm writing something using glib's process spawning features. A silly
example of what I'm doing might look something like this:
static void
foo (const gchar* path)
{
gboolean ret;
gint stdout;
gchar* argv[] = { /usr/bin/man, -R, utf-8, NULL, NULL };
argv[3] = path;
ret = g_spawn_async_with_pipes (NULL, argv, NULL, 0, NULL, NULL,
NULL, NULL, stdout, NULL, err);
if (!ret) {
// Do error handling here
}
// Use the file descriptor from stdout.
}
I've just been browsing through the code in glib's gspawn.c and I
*think* that, since it works by calling fork() then exec(), the strings
pointed to by argv are copied on the line with the
g_spawn_async_with_pipes() call.
My first question is, is this right? That is, am I safe to write
g_free (path)
just before the error-checking code, for example? (Yes, I know that
would be silly, but I want to understand what's going on :-) )
If so, I have a second question/suggestion. Should the documentation for
the async spawning functions have an explicit comment saying that the
memory is copied? Maybe developers with more experience with fork() and
exec() see that this is obvious but I, for one, didn't!
Thanks,
Rupert
pgp4hYnoV2wH4.pgp
Description: PGP signature
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Pointers and spawning processes with glib
On 10 December 2010 11:36, Rupert Swarbrick rswarbr...@gmail.com wrote: Hi, I'm writing something using glib's process spawning features. A silly example of what I'm doing might look something like this: I've just been browsing through the code in glib's gspawn.c and I *think* that, since it works by calling fork() then exec(), the strings pointed to by argv are copied on the line with the g_spawn_async_with_pipes() call. Since spawn creates a new process, the argv and envp arrays must be copied because the new process cannot access the address space of this process. My first question is, is this right? That is, am I safe to write g_free (path) yes just before the error-checking code, for example? (Yes, I know that would be silly, but I want to understand what's going on :-) ) If so, I have a second question/suggestion. Should the documentation for the async spawning functions have an explicit comment saying that the memory is copied? Maybe developers with more experience with fork() and exec() see that this is obvious but I, for one, didn't! It is pretty obvious it must be copied, even on windows where fork/exec doesn't exist. Cheers Lex Thanks, Rupert ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
