Hi Atamert, yes, that is also wrong usage that is not caught. I do want to focus on the current change though.
So the thought behind this change is that the birth-thread check was unnecessary or too strict from the beginning and people should just use transients correctly, caveat implementor. No more kids gloves. There is a paragraph <http://clojure.org/transients> dedicated to enforcement of thread-isolation, which I think is great. I also understand we want to give programmers more flexibility in using transients in other (mutlithreaded) contexts where the user knows it will be safe. I just think throwing away the entire safeguard is overkill and it's making unsafe Clojure code not only really easy, but even the default in the case of transients. All programs not using core.async could benefit from the owner-check. Again, like Alex suggested, a flag like (transient m {} :thread-isolated? false) or something (with the default to true) would at least ease my mind a bit. It would also alert programmers in core async when they see it, that they need to make sure only one logical thread should have access. >> But they would run fine, if you used delay's instead of future's. Same > wrong usage, single threaded. So the issue is not really this new change. > > (See my code with delay's earlier) > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
