>> I was wondering how I can introduce more concurrency in the problem.
>
> It's not exactly trivial. The essential issue is to decide on what a  
> good
> default policy for concurrent programming by users is. In my  
> understanding
> it's simply too hard to constantly deal with locks, critical sections  
> etc.
> The policy that I ultimately settled upon was simply to define that  
> programs
> run until they are complete or they block (where blocking is defined as
> "waiting on external event"). Interestingly, it seems that Scratch is
> following the same idea which is maybe not so surprising - in the end  
> that's
> what the stepping policy does, just in a more general way (#step  
> always runs
> to completion or until it waits for the next #step event).

I see. I was wondering if I was idiot because my problem is quite  
simple (at least
the requirements :)).

>> I will try to see how I can make a workspace that does not create the
>> deadlock and play with the solutions suggested by boris.
>
> The real trick here is that you can't have the "scheduler process"  
> (which
> organizes the individual steps) do the work since if it does, it will  
> block
> and thusly fail to organize any other activities. IOW, you need to  
> decouple
> "step scheduling" from "step evaluation" - once you do that it'll work
> nicely.

Yes I felt that too. Trying to thread the evaluation.

> Be warned though that getting the scheduling right has a few very
> subtle implications which aren't obvious at all.

Thanks for the warnings.
>
>> I was wondering if other people using Morphic for simulation did not
>> get the same problem
>
> Well, at least me and John both ran into the problem and came up with  
> very
> similar solutions ;-)

I can understand because what I want is just a bit more than  a morph  
animating
itself :). Ok I see. I like the hear that because I not good in  
concurrency generally
but I always fall on non-trivial stuff which confirms to me that we  
still do not have
a good abstraction for concurrency (but may be this is just ebcause  
this is complex).

Stef

>
> Cheers,
>   - Andreas
>
> ----- Original Message -----
> From: "ducasse" <ducasse at iam.unibe.ch>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Saturday, January 31, 2004 11:57 PM
> Subject: Re: Multi-thread Question in Morph?
>
>
>>> Your problem is that the UI process (which is responsible for  
>>> invoking
>>> #step) waits for the promise to compute its value. However, that
>>> promise
>>> will only be evaluated upon the next step, which would have to be run
>>> via
>>> the UI process which blocks on the promise. In short, you have a
>>> classic
>>> deadlock.
>>
>> Yes I see that :). Naively I was thinking that Morphic was more
>> concurrent.
>> I was wondering how I can introduce more concurrency in the problem.
>> I'm bit afraid by the idea of forking
>> the stepping mechanism.
>> I will try to see how I can make a workspace that does not create the
>> deadlock and
>> play with the solutions suggested by boris.
>>
>> I was wondering if other people using Morphic for simulation did not
>> get the same problem
>>
>> Stef
>>
>>
>> On 31 janv. 04, at 23:03, Andreas Raab wrote:
>>
>>> Hi Stef,
>>>
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>> ----- Original Message -----
>>> From: "ducasse" <ducasse at iam.unibe.ch>
>>> To: "The general-purpose Squeak developers list"
>>> <squeak-dev at lists.squeakfoundation.org>
>>> Sent: Sunday, February 01, 2004 1:52 AM
>>> Subject: Multi-thread Question in Morph?
>>>
>>>
>>>> Hi all
>>>>
>>>> I'm designing a simple environment with a bot evolving in a maze.  
>>>> The
>>>> user can control the bots from a kind of workspace.
>>>> In an old implementation, I did not use step and put some delay and
>>>> World doOneCycle. Not so good. I decided to
>>>> clean that and  to use the step method to execute commands sent to
>>>> this
>>>> morph.
>>>>
>>>>
>>>> The morph has a queue of actions (which are reified message sends  
>>>> with
>>>> a future to hold their result).
>>>>
>>>> For example the method go is implemented as
>>>> NewBot>>go
>>>>
>>>> self addAction: #goPrimitive
>>>>
>>>> this means that when the action is executed the method goPrimitive
>>>> will
>>>> be executed which is in fact implemented.
>>>>
>>>> goPrimitive
>>>>
>>>> self position: (self position + (10 at 10))
>>>>
>>>> addAction: and similar methods are implemented that way: a command
>>>> object is created and put in the queue and returned.
>>>>
>>>> addAction: aSelector arguments: anArray
>>>>
>>>> | anAction |
>>>> anAction := (BotCommand selector: aSelector arguments: anArray).
>>>> actionQueue addLast: anAction.
>>>> ^ anAction
>>>>
>>>> A command object is a message reification that holds a future so  
>>>> that
>>>> I
>>>> can get result back to the sender when necessary (for exmaple getter
>>>> method, as in the following example. result in that case get the
>>>> future
>>>> and ask its value.
>>>>
>>>> diamNumber
>>>>
>>>> ^ (self addAction: #diamNumberPrimitive) result
>>>>
>>>> The step method goes over the queue and execute the actions one  
>>>> after
>>>> the other. It then puts the future value
>>>>
>>>> step
>>>>
>>>> | action res |
>>>> ^ actionQueue isEmpty
>>>> ifFalse: [action := self removeAction.
>>>> res := self perform: action selector withArguments: action
>>>> arguments.
>>>> action setFutureValue: res]
>>>>
>>>>
>>>> Now I have the following problem that you can try just by loading  
>>>> the
>>>> cs.
>>>> If I create a morph NewBot new openInWorld, inspect it and execute
>>>> self
>>>> diamNumber in an inspector, the complete environment
>>>> is blocked.
>>>>
>>>> I simplified the problem to its essence in the attached file. If you
>>>> open an inspect and evaluate self diamNumber
>>>> the system freezes. Apparently there is not enough thread in  
>>>> morphic.
>>>> So I started to see where I could
>>>> put another thread. The problem is that
>>>> - in an inspector doing [self diamNumber] fork does not help  
>>>> because I
>>>> would need another future to get the value form the thread
>>>> - opening an inspector in another block (self inspect fork) and in
>>>> this
>>>> new inspector doing self diamNumber still freezes the system
>>>> My impression is that the UI scheduler does not let me doing that.
>>>>
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------- 
>>> --
>>> -----
>>> ----
>>>
>>>
>>>>
>>>>
>>>> does anybody has an idea of how I could solve that problem?
>>>>
>>>>
>>>>
>>>> stef
>>>
>>>
>>> --------------------------------------------------------------------- 
>>> --
>>> -----
>>> ----
>>>
>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>