Hi Denis, > Problem that concurrent modification of OrderedCollection could just fail. > You will got debugger.
Yes, effectively, if there are multiple threads that try to add an handler on the same element at the same time, this could just fail. To me, it is not a problem, it is just a rule: the scene graph is not thread-safe. When a developper have to do this kind of specific stuff, he has to know that it is really not recommended and that he has to manage concurrency by hand. But yes, he could use #runLater:. Maybe, Bloc will have to provide kind of Task (using TaskIt?) with a specific api to ease ui synchronization using concurrency (later). > In that case what to do if I need to be sure that I really subscribe on > event and only after this continue my business logic process? Weird use case, you mean that sometime your business behavior declared after a subscription needs that the subscription have to be called before continue? Please can you be more explicit? For what i understand, it look like a workaround or a conception issue. > Very simple example: I want one shot handler for MouseMove to highlight > element once to see that my mouse was moved around. > So my handler will highlight target element and unsubscribe it > immediately. > Problem that if you do it on OrderedCollection during iteration you could > skip one of the handlers. And probably some failures are also possible > (debugger again). Yes, thanks for pointing this issue, i didn't remember that #select:thenDo: uses the index at each iteration. I will update that using (handlers select:[...]) do:[...] instead. Since #select: create a new collection, there should not be any problem. > But in practice we never share any announcer instance. We always hide it > inside owner object. ValueHolder is not specific example. > Also ValueHolder is kind of active model for UI application which could be > shared between different views. And when it will be modified in one view > another view will be updated automatically. I know what is a ValueHolder and how data binding is usefull in GUI. I didn't say that NewValueHolder and Announcer are not good and i don't think that, i just asked myself about why the use of Announcer in NewValueHolder make it 5x slower only to ensure that it is thread-safe while in most cases, all stuff is done in one thread. It is why i didn't use NewValueHolder in Bloc. (I commited tests between NewValueHolder and BlObservableProperty in Bloc-Tests). If performances was not a critical issue in Bloc, obviously i would have used NewValueHolder and Announcer because there are well done and well tested. > I wondering what the source of this constraint? Does Morphic follows it? I > guess not, but all Pharo works quite well with it. Just move you mouse quickly on screen and think about how many MouseMoveEvent are generated by the system. Yes, Morphic follows it. Morphic doesn't use Announcer for UI events and concurrent modifications of a morph seems to be not thread-safe. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913412.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
