I think that this is the morph scheduler model that is wrong.
but unfortunately I'm not good enough in concurrent programming to
fix. I remember that once nathanael told me that it was bogus by  
construction
and that he understood how to do a good one. Too bad google took him :)

On Dec 24, 2008, at 4:19 PM, Damien Pollet wrote:

> On Wed, Dec 24, 2008 at 14:27, Stéphane Ducasse
> <[email protected]> wrote:
>> yes but so far none of the moprh class specialised this method.
>
> it's not used => remove it
>
>> On Dec 24, 2008, at 2:00 PM, Alexandre Bergel wrote:
>>> It depends whether it makes sense or not to have a different  
>>> threshold
>>> for objects.
>
> I'm not convinced by that threshold thing. If you need to update
> something, either you have realtime constraints, or you just want to
> limit CPU usage, in which case it's the scheduler's responsibility to
> respect whatever low priority you give to the update task… no?
>
> -- 
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to