March 13, 2002
I was thinking about foreach() functions and such, and got to thinking about the possibility of returning an array from a collection object that would be an array of the iterators of the elements in the collection.  Then you could iterate through the array, doing something on each one.

Of course, that array would only be valid as long as the collection didn't change, which, in a multithreaded program, means you need locks. So I was ending up with a class (in my head) that wrapped the array. The collection would get locked when you called GetIteratorArray() or some such, and it would get automatically unlocked when the destructor for the class ran.

Of course, this is problematic, since other threads might grab for the lock and block (since the lock is already owned), and the collection would not be unlocked until the garbage collector ran.  Thus, we would need some mechanism to force the GC to run so that the lock would get released.  I can see a couple of hacks:

* put the waiting thread in a while loop - call the GC, check the lock,
sleep a bit, repeat
* force programmer to delete the array when he's done with it...but if
he does that, then he might as well just have a basic array and manaully
lock/unlock the object

Are there any other ideas how you might do this in D?  I'm hoping for a very efficient solution with minimal requirements on the programmer.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]


March 13, 2002
"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8F85A1.3E475065@deming-os.org...

> * put the waiting thread in a while loop - call the GC, check the lock, sleep a bit, repeat

It would be very slooooooow to have garbage collected again and again.

> * force programmer to delete the array when he's done with it...but if he does that, then he might as well just have a basic array and manaully lock/unlock the object

I don't really see any alternatives to this one. Since the lifetime of your object is not guaranteed in any way when left on its own, it must be deleted explicitly...