Lex Trotman <elextr gmail com> writes: > On 10 December 2010 19:02, Robert Pearce <rob 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
Attachment:
pgp01x0umikmb.pgp
Description: PGP signature