#threadsafe

[babesareblue]

[suisui-tech]

[suisui-tech]

[ioswallofshame]

Threadsafe sometimes.

[kares]

Preventing Recursion in Ruby (without Thread.current)

This post is inspired by Preventing Recursion in Ruby. First a confession: every time I see Thread.current[] I start thinking of ways to eliminate it. Thus I believe there's at least one thing wrong with the approach presented in the post. Let's try rebuilding prevent_recursion : embedGist('https://gist.github.com/1722780.js?file=prevent_recursion.rb') It seems to serve almost the same purpose and using an object's singleton class just feels right. Please note, that this does not behave exactly the same way compared to the threaded solution - we prevented a method from recursing once (or "forever" if we remove the (class << self) line), however this should most likely suffice. Of course, I only got "smart" by failing previously, but since than I always think twice over storing anything in Thread.current, which is one of the most abused patterns in Ruby and no matter how uniquely you name those variables it's still a smell. Maybe it's about time thread-safe frameworks, such as Rails, should provide us with an abstraction for safely storing thread local data. Now, I should probably end this right here - point proven. But since the post mentioned infinite recursion with ActiveRecord::Callbacks I immediately remembered my very own case where I would be of no luck using the above approach. Try the following sample : embedGist('https://gist.github.com/1722780.js?file=sample_2.rb') A real world scenario would be keeping an array-like index for items in a basket. Each basket has it's items ordered and changing an index of an item "swaps" it with the other item at the given position. One way of doing it, which requires a recursion prevention would be : embedGist('https://gist.github.com/1722892.js') Notice how the method gets redefined with a dummy one to prevent recursion. I'm a huge fan of doing things DRY, on the other hand sometimes it might be contra-productive, especially when it can't cover all cases or is only used once or twice. Not to mention how much easier it would be for a new comer to read a method such as assign_index and understand the trick immediately then having to dive deep into another module's meta-stuff. UPDATE: As @avdi pointed me out, I realized I'm actually promoting non-thread-safe code. I narrowed my recursion prevention domain to short lived AR instances that are never accessed beyond a single request, however this is clearly not a completely valid assumption to make. Especially since the original prevent_recursion targets a much wider audience. Notice the difference in behavior if the prevented (thread-safe) instance method or a shared object is accessed by two concurrent threads, Thread.current will guarantee a correct result for each caller, however my instance_eval approach will not. And so the moral of this story seems that a slice of Thread.current[] "pollution" to prevent recursion is inevitable after all.

[kares]

Rails.logger is not threadsafe!

At least not completely, one might experience strange logging issues especially in JRuby threadsafe! environments: logs show up fine in the beginning but after a while it seems as if logging stopped working and only errors show up. Blame ActiveSupport::BufferedLogger for not being (completely) thread-safe, let's take a closer look at it's silencing implementation : embedGist('911222.js') Consider there are 2 threads running logger.silence(&block) concurrently. Thread 1 enters the silence blocks and changed the (temporary) level to ERROR. Then thread 2 comes in and changes the level for the block duration but the old_logger_level is now ERROR, as thread 1 changed the level already (and haven't finished executing the block yet). Now suppose thread 1 is done and restores the correct level, next thread 2 finishes and it also restores the "old" level leaving logger.level different then it was before both threads invoked silence ! Now that we understand what's happening, there seem to be 3 options how to fix this :

No silencing: ActiveSupport::BufferedLogger.silencer = false

Setup a new logger instance for every request (thread)

Use a thread-safe "silencable" logger, such as the following:

embedGist('911210.js') This actually does more then promised. Would be great if we haven't had to pollute Thread.current, unfortunately there are places where silence is reinvented instead of being delegated to the logger, thus the "crazy" level= writer. In a perfect world a silence tweak would do the job. Even if one does not use logger.silence and it's siblings such as ActiveRecord::Base.silence explicitly, it might get called by the framework e.g. when a session is being loaded using ActiveRecord::SessionStore. It's best to make sure logging works correctly in a concurrent environment as tracking down production issues when one can not rely on logs is not that simple.

[borislit]

While building a web application using Java Servlets, I've used Singelton to manage Facebook API interactions and calls. The class held a variable holding FB access token used by the current user. However, I later discovered that Singelton (just like static class) is shared among all threads/request to the given servlet, causing the user's access token to be overwritten. I came upon ThreadLocal as a solution for cases just like mine.

The class allows assigning value per thread for a given variable. Thus each Thread (representing a single user) will have a "local" value of the token, making it thread safe.

The article provide an overview of the class and its usages.