Re: Pointers and spawning processes with glib

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lex Trotman <elextr@xxxxxxxxx> writes:

> On 10 December 2010 19:02, Robert Pearce <rob@xxxxxxxxxxxxxxxxxxxx> 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: pgpvFTUmRBn20.pgp
Description: PGP signature

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux