On Jun 7, 2008, at 6:59, Ricky Sharp wrote:
I will hope though that within the context of say memcpy, that the
GC thread could not collect data. For example, the following
should be safe:
memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);
No. This is equivalent to:
void *tmp073495 = [data bytes]; // <<<<<<< last use of 'data', as
previously discussed
... other "harmless" stuff could be put here by the compiler ...
// <<<<<<<<< GC could run here, or not; mystery crash 0.7% of the time
memcpy(myLocalGCAwareBuffer, tmp073495, numberOfBytes);
to the compiler. There is a sequence point between the evaluation of
all the function call arguments and the call to the function, but it
doesn't follow that the two things are right next to each other.
Depends on what else is going on in the surrounding code. The
sequence point just ensures that all side effects from the argument
evaluation are complete before the function begins.
On 7 Jun 2008, at 09:07, Antonio Nunes wrote:
On 7 Jun 2008, at 06:16, Ken Thomases wrote:
The issue is, how can one know when this technique is necessary?
By proper documentation. As Bill mentioned earlier, the
documentation needs to mention this behaviour. Just as retain/
release, GC has its own caveats, it's own moments where one has to
take special care. This appears to be one of them. If I read Bill's
explanation correctly then once the documentation gets updated and
distributed anyone can know when this technique is necessary (as
long as they know what they're doing, which goes for anything in
programming).
<sarcasm>Oh, yes, it's just that simple.</sarcasm> Even
understanding the potential does not necessarily lead to recognizing
when special action needs to be taken. In amongst the hundred other
things you have to keep in mind as you write a method, there will
also be, "let's see, is this the last use of this object in this 100-
line method? <scroll, scroll> Hmm, yes, it appears so. Let's see,
do I need to take any special actions ...? OK, now what about this
next object ...?" etc. And what about code which already exists,
such as "millions" of lines of Cocoa/ObjC code in the OS frameworks?
Somebody has gone over years of accummulated "optimized" code with a
fine-tooth comb to find such things? I'll say no more; these are
just hypothetical statements pointing out the shallowness of a
"documentation bandaid" approach.
It'd be much better if the tools could warn you about such things in
the source code. Or something.
I think Bill summarized this whole discussion, and 90% of other
garbage collection discussions, brilliantly in these 8 words:
On 6 Jun 2008, at 16:42, Bill Bumgarner wrote:
Under GC, the situation isn't quite so clear.
Once upon a time, for this kind of thing, people would say things
like "That's going in my quotes file!", ... back when people kept
quotes files....
On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
Quoting the Garbage Collection Programming Guide: "The initial root
set of objects is comprised of global variables, stack variables,
and objects with external references. These objects are never
considered as garbage"
For some values of "never".
This, and the so-called "C code" using the bytes pointer from a data,
reminded me of some lines from a Gilbert and Sullivan opera ...
GC: [...]
I am never known to quail
At the fury of a gale,
And I'm never, never sick at C!
Chorus:
What, never?
GC:
No, never!
Chorus:
What, never?
GC:
Hardly ever!
Chorus:
He's hardly ever sick at C!
[...]
Chris
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
