The way I talked about it on the other forum was that all message sends could be concurrent, but a #continuation: message could be added to Object to allow sequential execution.

On second thought, there are other approaches that would probably be easier for people to deal with. Some other ideas knocking around my head are:

1) message receipt is concurrent, but message sending is blocking. We’d still need to keep the BlockClosure>>fork, and the futures/promise mechanism for concurrent execution of a block of code.

One of the points made by another participant in the discussion on the other forum was that in any program or system there’s a need for some execution to be sequential (or blocking). Not everything can run in parallel.

2) Maybe lazy evaluation behavior would fix that. Just assume concurrent execution until there’s a dependency, and then block on that dependency unless otherwise specified. This is like futures, but it would be an inherent part of how the system works.

I agree. This sounds like a better approach. The thing is, what about the state changing methods in its base classes as well? Not everything that’s useful about an OrderedCollection is in that class.

Something I’ve been exploring conceptually with another blogger just recently is the idea of a concurrent OOP, redefining the semantics of it so the whole system is concurrent by design, with an allowance for sequential execution. The link points to my comments about this. The comment I was responding to is instructive as well, though I’m sure you’re familiar with the metaphor being discussed.

I don’t have the first clue about how to actually implement it yet, but I was just throwing about some ideas. When I look at OOP as defined by Kay, it seems natural that just as there is concurrency on the internet, there can be concurrency between objects. It seems like this is going to be needed fairly soon, don’t you think?

Don’t know anything about video, sorry.

We could use the blog example you had earlier in Seaside, where you store blog posts and comments to them in OrderedCollections. You eventually went to a database, but I remember you said you wanted to use it only as a backup, that you would keep data in memory along with the database.

What I remember is you had the “component thread” (in Seaside), I guess, add to the OrderedCollection, but this creates a problem of multiple threads potentially adding to the collection at the same time. I’m talking about a shared resource.

You could use a critical section for this, inside an #add method in the class where you kept the OrderedCollection, I guess:

Blog>>add: comment
| sema |
sema := Semaphore forMutualExclusion.
sema critical: [comments add: comment]

There’s also the issue of sharing data between threads. I’ve heard others say SharedQueue is the best way to handle that. I’ve tried it and it works. I was trying out some code to see if I could do screen recording in Squeak. I got a little something working. In one thread I captured forms (frames) of the whole screen and put them into a SharedQueue. Another thread on a lower priority listened on the SharedQueue, grabbed frames out, and saved them to individual files. Later I could play them back, using a different routine, to see how it worked out.

BTW, perhaps this is out of your area of expertise, but maybe somebody else knows. Where could I find specs on video file formats? I tried looking up MPEG-1. The results I got indicated that somebody owns the rights to it, and you have to pay to get the spec. Is that correct?

I was planning on doing another example of a Promise next which is like a future anyone can fulfill.

However, having a look at the VisualWorks implementation, I can see why they implemented Promise instead of Future since Futures can be implemented via a promise from a forked block. Interesting indeed.

http://www.gnu.org/software/smalltalk/manual-base/html_node/Promise.html

Promise