Rubric mutability issue in RubTextComposer binary search

Hi,

Why is that an issue in Rubric?

Because I can reproduce it only in Rubric :)
Rubric is great and it's a pleasure to use it!

I'm just curious if there is a possible quick fix. I guess, I have an idea why it could happen (because rubric for styling uses it's own background thread and doesn't absolutely takes care if during styling in its inner threads text changes) but I'm not sure if I can find time in the very nearest future to fix it, or at least try.

Why do not ensuring in spotter that only one thread at a time can modify the text editor?

That is the most interesting part. In spotter I can guarantee that at any time always maximal only one thread have access to UI elements. But I can't guarantee that this thread is UI one. It is important. I build some widgets completely in background and then pass them to UI thread to be added in the World. By convention in Spotter only UI thread can add and modify widgets in the world. If widget not in the world it can be modified by any thread, but only one.

I tried to reproduce the issue, so there is a synthetic examples: (huge numbers to increase probability of exception)

It works for text edit morph:

|morph random|
morph := TextMorphForEditView new.
morph openInWindow extent: 400@400.
random := Random seed: 1337. 

[ 1 to: 1337 do:
[ :i | morph contents: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork

The same doesn't work for rubric:

|rubric random|
rubric := RubScrolledTextMorph new beForSmalltalkCode.
rubric openInWindow extent: 400@400.
random := Random seed: 1337.
[ 1 to: 1337 do: 
[ :i | rubric updateTextWith: (String loremIpsum: (random nextInt: 1337) + 42) ] ] fork
 

Why do not ensuring in spotter that only one thread at a time can modify the text editor?

yes, if no solution is found I will always create rubric morphs in UI thread

Thanks for answers 

 

Cheers,

Alex

On Wed, Mar 18, 2015 at 1:45 PM, Guillermo Polito <[hidden email]> wrote:

I agree with Stephan... I don't think that Rubric is built to be thread safe.

Also, making Rubric thread safe will probably be a lot of work... Why do not ensuring in spotter that only one thread at a time can modify the text editor?

El mar., 17 de mar. de 2015 a la(s) 11:42 p. m., Stephan Eggermont <[hidden email]> escribió:

Hi Alex,

On 17/03/15 22:19, Aliaksei Syrel wrote:
> seems like there is a rather rare bug in Rubric. I opened an issue with
> explanation:
>
> https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability-issue-in-RubTextComposer-binary-search
>
> Would be nice to fix it until release. It was caught in Spotter - as it
> heavily uses multithreading. Any suggestions are welcome if it is known :)

Why is that an issue in Rubric? Sounds like you might need a monitor in
Spotter?

Stephan