ferdy89 / unique_thread Goto Github PK

There's a Gitter channel for this project now in https://gitter.im/ferdynton/unique_thread so we should make that public in the README in case anybody has questions or suggestions

The interface would look like:

UniqueThread.loop('lock_name', sleep: 30) do
  # do something every 30 seconds
end

This seems to be the most common use case for this gem so far, so it makes sense to have a shorthand for it.

The way the gem is shaping, the run interface will be the "raw" one for a thread that mimics the Ruby one, while loop is the advanced one with features like looping, sleeping and now retrying.

Besides the written explanation of the use cases in the README, we should have a directory with some live code examples. This should help folks integrate them into their projects without having to think too much.

This interface will replace:

UniqueThread.new('lock_name').run do

and transform it into

UniqueThread.run('my_lock') do

This simplifies the public interface and makes it similar to the one from #5.

On a previously reported issue it was mentioned that there's no way to exit a UniqueThread. If an error occurs, the thread dies but it keeps the lock.

We should have some sort of UniqueThread::ExitError that a user can throw to terminate the thread AND liberate the lock.

The unit tests currently use a few calls to sleep with very small waits in order to give control to the thread.

These calls don't hurt "much" to the test time because the few tests we have run in a couple seconds anyway. However, it probably is a smell of a lack of understanding of how we interface with the gem.

For example, if the gem was a regular Thread, the proper way of handling control to it would be to wait. However, the gem it's not really a thread, so this is not possible.

The point of this task is to go in that direction: think (and implement) a way to test UniqueThread in a similar way that one would deal with a regular Thread