Not threadsafe about go-observable HOT 9 CLOSED

Yes you are right, I am not yet sure if I want to use the RWMutex or just to get rid of the goroutines and the whole async strategy. Any pull request (with tests) is welcome ;)

from go-observable.

I want also to benchmark the 2 strategies async vs sync

from go-observable.

Sync could work, users could make triggers async with go o.Trigger(...). I guess there's an issue of each event would trigger in series. Another option is o.GoTrigger(...), which internally would call each callback in it's own goroutine.

RE: Performance: I think just go with a Mutex for now, modifying a map and unlocking is much faster than any use of reflect, so I don't think it will matter too much at this point.

from go-observable.

thanks for the hint I will come back here asap without changing tha API of the script

from go-observable.

the new version should be thread safe.. can you please have a look?

from go-observable.

Still appears to have possible races. Every instance in the code which performs a write (e.g. o.Callbacks[event] = ...) could possibly be run concurrently should be protected with a sync lock. Note, concurrent reads are okay if there are no concurrent writes.

from go-observable.

But running go test -race there are no errors traced anymore. Can you provide an example I could test where there could be a race condition?

from go-observable.

I don't actually use go test -race much, though I probably should. I just
think about which code paths which could possibly be run by multiple CPUs
at once. I probably should use go test -race more...

On Thu, Jan 21, 2016 at 9:22 PM Gianluca Guarini [email protected]
wrote:

But running go test -race there are no errors traced anymore. Can you
provide an example I could test where there could be a race condition?

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

from go-observable.

this issue was solved with 0ca0ceb thank you for your help

from go-observable.