In this question I posed to stack overflow, an answerer claims that rails is only threadsafe when using MRI: http://stackoverflow.com/questions/22428949/ Anyone have any thoughts on this?
on 2014-03-17 02:42
on 2014-03-17 03:16
I am not sure how thread safety or lack there of is the cause of this problem. There was once an issue with IO#reopen and how there are certain assumptions being made about what reopen is trying to do: ( http://jira.codehaus.org/browse/JRUBY-5222) def silence_stream(stream) old_stream = stream.dup stream.reopen(RbConfig::CONFIG['host_os'] =~ /mswin|mingw/ ? 'NUL:' : '/dev/null') stream.sync = true yield ensure stream.reopen(old_stream) end I wonder what active_support is trying to do quietly... Ariel Valentin e-mail: firstname.lastname@example.org website: http://blog.arielvalentin.com skype: ariel.s.valentin twitter: arielvalentin linkedin: http://www.linkedin.com/profile/view?id=8996534 --------------------------------------- *simplicity *communication *feedback *courage *respect On Sun, Mar 16, 2014 at 9:40 PM, John Joseph Bachir <
on 2014-03-17 03:22
There is already an issue about this posted on the activerecord-session_store github issue tracker: https://github.com/rails/activerecord-session_stor... It is also noted in the ruby on rails documentation that the silence_stream method is not thread-safe: http://api.rubyonrails.org/classes/Kernel.html#met...
on 2014-03-17 03:30
Ouch. Any idea how pervasive this issue is? i.e. how dependent is rails on silence_stream? Ariel Valentin e-mail: email@example.com website: http://blog.arielvalentin.com skype: ariel.s.valentin twitter: arielvalentin linkedin: http://www.linkedin.com/profile/view?id=8996534 --------------------------------------- *simplicity *communication *feedback *courage *respect
on 2014-03-17 03:38
Rails itself will never use silence_stream in production. This is the activerecord-session_store which is using silence_stream (which it shouldnt). The activerecord-session_store was extracted from the rails repository and is not the default rails session store for good reason. My suggest is to switch to the rails session store to the cookie_store which is the default session store and is thread safe.
on 2014-03-17 18:32
As I did mention on SO - Rails being "only-truly" MRI thread-safe - means from time to time there's an assumption that only works with the GIL. There's similar issues around e.g. as noted in the gist with silencers https://github.com/rails/rails/issues/12477 or https://github.com/rails/rails/issues/12477 Logger.silence and others got fixed along major releases ... but got back in on master/4.1 :) https://github.com/rails/rails/blob/master/actives... in the case of silencers there's usually the way know to disable them using a class accessor. It's pretty simple to monkey-patch **silence_stream** in this case to simply yield and not do any silencing if thread-safety is a primary concern and AR::Store will work just fine ... also, it's certainly great to know it's not used that much but still one can not be sure some gem using Rails API will not eventually call it, it's part of the API as it is after all. K.