In this question I posed to stack overflow, an answerer claims that
rails
is only threadsafe when using MRI:
ruby on rails - ActiveRecord "IOError: could not reopen: null" - Stack Overflow
Anyone have any thoughts on this?
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 V.
e-mail: [email protected]
website: http://blog.arielvalentin.com
skype: ariel.s.valentin
twitter: arielvalentin
linkedin: Sign Up | LinkedIn
*simplicity *communication
*feedback *courage *respect
On Sun, Mar 16, 2014 at 9:40 PM, John Joseph B. <
There is already an issue about this posted on the
activerecord-session_store github issue tracker:
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#method-i-silence_stream
Ouch. Any idea how pervasive this issue is? i.e. how dependent is rails
on
silence_stream?
Ariel V.
e-mail: [email protected]
website: http://blog.arielvalentin.com
skype: ariel.s.valentin
twitter: arielvalentin
linkedin: Sign Up | LinkedIn
*simplicity *communication
*feedback *courage *respect
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.
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
3.2.x - with `config.threadsafe!`, logger will be stuck at ERROR after running for awhile · Issue #12477 · rails/rails · GitHub or
3.2.x - with `config.threadsafe!`, logger will be stuck at ERROR after running for awhile · Issue #12477 · rails/rails · GitHub
Logger.silence and others got fixed along major releases … but got
back
in on master/4.1 
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/logger_silence.rbalthough
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.