You keep talking about the performance hit of locking the array...
I don't know what Slang support for garbage collection has been written but
all you need is something that should be free!  All you want is to make sure
that the array you're iterating over doesn't go away until after the
iteration is done.

One of these two things (some form of this is NECESSARY if you ever want run
bytecodes in parallel with Slang code or call bytecodes from Slang code):

1.  The ability to register some Slang/C variables with the garbage
collector so that what they point at will not be collected and so that those
variables will be updated if the object moves.

or

2. The ability to register some variables Slang/C variables with the garbage
collector so that what they point at will not be collected and to lock the
object so that it will not be moved.  This could be more expensive.

Also, because of the become: problems you either want a restriction so that
Slang/C variables are never replaced on become: (that might be good enough).
Or you want to make become replacement optional on a per/varible basis.
....

Why should keeping an object from being collected be expensive at all?



----- Original Message ----- 
From: "Tim Rowledge" <tim at sumeru.stanford.edu>
To: <jscholar at access4less.net>; <squeak-dev at lists.squeakfoundation.org>
Sent:  Wed Dec 1 21:56:55 CET 2004
Subject: Re: Adding loop primitives/optimizations (was Making
Set/Dictionaryetc. loops more robust)

>
>>
> In message <034b01c4d7e1$e00d7bd0$3fe22641 at antssoftware.com>
>           "Joshua Scholar" <jscholar at access4less.net> wrote:
>
>> Your example would NOT see the new elements because
>> SequenceableCollection>>do: is implemented as:
>>
>> do: aBlock
>>  "Refer to the comment in Collection|do:."
>>  1 to: self size do:
>>   [:index | aBlock value: (self at: index)]
>>
>> See, end of the array was computed before the loop started.
>>
>> If you shortened the array, you would have an error pop up.
> Ah, run the code and see what fun it causes. I guarantee you'll see new
> elements, though they may not be ones you expect. Welcome to... The
> Become Zone!

That's silly.  If you lengthen the array, it will have already have
calculate the end point of the iteration before the first block invocation
and will stop at the precalculated point. End of question.


>>
>> "become:" affecting an active iteration is wrong.  Iterations can only be
>> clean if they're over a snapshot not over a live collection anyway.  Ok,
we
>> can't afford pure cleanness but there's no point in pushing the language
>> toward an idiom that can't even be defined without contradictions.
> I'm not championing anything here except realism about how much mess
> one can trivially (and usually unexpectedly) get into when trying to
> think of optimisations like this. As you say, to be 'safe' one has to
> somehow lock the collection but I'm not convinced there is actually a
> real way to do that. And the performance hit could be appalling.
>
>
>>
>> What if "become:" changes the type of array to a different type?
>>
>> You could argue that an array of a different size IS a different type.
It
>> is in many languages.
>>
>> No, THERE IS NOTHING WRONG locking down the array and iterating over it.
>> If the code calls "become:" then continuting the iteration over the old
>> array is no worse than trying to continue a loop over the new (I would
say
>> "wrong") object.
> Err, using become: makes the new array into the original one - that's
> the whole point of become:, after all.

The whole idea of calling become: on an object with active methods is nutty.
anObject is an isntance of class Foo and is running a method doSomething:
onABlock, and that block makes anObject become: an instance of class Bar,
then when it gets back to doSomething, suddenly it's in method of Foo with
"self" refering to an instance of Bar.  That's an illegal state of mind if
I've ever heard of one.

If you call become: on an object with a running method, you're lucky if you
don't get a crash.  Frankly I can imagine an argument that "self" shouldn't
be replaceable - and that become should cause an error if there's an active
"self" refering to the original.

If you CAN replace self on a running method and get a sane result, THAT'S a
f***ing miracle.

>>
>> In fact, finishing the iteration with the object you started with _is_
>> _cleaner_.
>>
>> If you don't agree with me on that, then maybe you'll decide that _it_
>> _doesn't_ matter_ _because_ _code_ _shouldn't_ _call_ _become_ _inside_
_of_
>> _and_ _iterator_ _on_ _that_ _object_.
> Well of course I agree with that - but you cannot enforce it in any way
> that I can think of that would be practical. You cannot restrict the
> effects of code called during the iteration, nor code running in other
> threads that might run during the iteration.

I'm not still not seeing a problem with making a primitive iterator as long
as we can guarantee that the source isn't garbage collected while the
iterator is running.

By the way I'm VERY used to multiprocessor multithreaded code.  In my last
job I spent a lot of time working out nonblocking algorithms for
multiprocessor code.

Joshua Scholar