Threading

Multi-threaded job backend with database queuing for ruby.

Multiton provides a transparent, thread safe and highly compatible implementation of the multiton (and singleton) patterns in pure Ruby.

A simple thread pool

Pubsub wrapper with utilities to chain events, sanitize payloads and record data on all events on the same thread.

Youtube Progress Bar Taggerextracts comment threads, comments, and comment of author from Youtube videos

MotionAsync was written for use with RubyMotion Android, and makes it easy to run code off the main UI thread by providing a friendly wrapper around Android's AsyncTask class.

A Ruby client that tries to match Redis2' API one-to-one, while still providing an idiomatic interface. It features thread-safety, client-side sharding, pipelining, and an obsession for performance.

Thread-safe collections and utilities for Ruby

Drop-in replacement for stdlib Timeout that uses POSIX interval timers instead of threads. Not as portable but much lighter weight. Also includes low-level wrappers for setitimer and getitimer.

Concurrently is a concurrency framework for Ruby and mruby based on fibers. With it code can be evaluated independently in its own execution context similar to a thread: hello = concurrently do wait 0.2 # seconds "hello" end world = concurrently do wait 0.1 # seconds "world" end puts "#{hello.await_result} #{world.await_result}"

Logmerge contains two utilities logmerge and ip2name. logmerge merges Apache access logs into one log ordered by date. ip2name performs DNS lookups on Apache access logs using multiple threads and Ruby's DNS resolver library to speed through log files.

Riser is a library of Ruby Infrastructure for cooperative multi-thread/multi-process SERver. This library is useful to make multi-thread/multi-process socket server and daemon.

Decouplio is a zero dependency, thread safe and framework agnostic gem designed to encapsulate application business logic. It's reverse engineered through TDD and inspired by such frameworks and gems like Trailblazer, Interactor.

Launch an array of Procs within threads.

EventMachine implements a fast, single-threaded engine for arbitrary network communications. It's extremely easy to use in Ruby. EventMachine wraps all interactions with IP sockets, allowing programs to concentrate on the implementation of network protocols. It can be used to create both network servers and clients. To create a server or client, a Ruby program only needs to specify the IP address and port, and provide a Module that implements the communications protocol. Implementations of several standard network protocols are provided with the package, primarily to serve as examples. The real goal of EventMachine is to enable programs to easily interface with other programs using TCP/IP, especially if custom protocols are required.

Get the Currently running Rack::Request from anywhere inside the request-thread

A new tftp library for clients and servers that supports RFCs 1350, 2347 and 2348 (ie. variable block sizes). It includes a sample client implementation, and a sample server implementation. The server is single-threaded and supports multiple simultaneous downloads.

Run simple workers in a separate thread

Get thread-like behavior from fibers using EventMachine.

CSV Files: I hate them, you probably do too, but sometimes you need to get data into your system and this is the only way it's happening. If you're deploying a rails app in a cloud setup, you may have troubles if you're trying to store an uploaded file locally and process it later in a background thread (I know I have). cumulus_csv is one way to solve that problem. You can save your file to your S3 account, and loop over the data inside it at your convenience later. So it doesn't matter where you're doing the processing, you just need to have the key you used to store the file, and you can process away.

== FEATURES: * DRb frontend * easy to use client library (see below) * multi index search * Index rotation Stellr always keeps two versions of your index around - one is used in a multi threaded, read only way to handle incoming search requests, while the other one is written to when you index something. Using the switch function you may decide when to switch over searching from the old index to the new one. Then, changes will be synced, and searches will see the new or updated data from before the switch call. * Index synchronization Two kinds of synchronization methods are supported for now: rsync, using rsync two copy over the changes from one index to the other, and static, which will completely replace the old index with the new one. While the latter is suitable for indexes which you rebuild completely from time to time, the former is good for large indexes that are updated frequently or that are too large for frequent rebuilds. == SYNOPSIS: * start the server:

This gem extends ActiveRecord to add additional functionality to JSONB - use PostgreSQL JSONB data for associations - thread-safe single-key updates to JSONB columns using `jsonb_set` - extended `table#references` for easy migrations and indexes - virtual JSONB foreign keys using check constraints (NOTE: real foreign key constraints are not possible with PostgreSQL JSONB) Inspired by activerecord-jsonb-associations, but for use in Rails 6+ and ruby 2.7+ and with some unnecessary options and features (HABTM) removed and some additional features added

API compatible Thread based Fiber implementation for Ruby 1.8 (including JRuby in 1.8 mode)

Main Loop implementation to control subprocesses and threads

Thimble is a ruby gem for parallelism and concurrency. It allows you to decide if you want to use separate processes, or if you want to use threads in ruby. It allows you to create stages with a thread safe queue, and break apart large chunks of work.

A simple wrapper for Ruby Threads and SizedQueue.

This rate-limited scheduler is made for requests to APIs with sensitive, time-critical access restrictions which means that even limits with short time intervals such as 5 requests per second can be hold in a multi-threading environment. It implements Redis-based execution handles.

Polymorphic threaded comments Rails plugin/gem

Adds Thread#backtrace for inspecting backtrace of a thread. Only supports 1.8

Armstrong is an Mongrel2 fronted, actor-based web development framework similar in style to sinatra. With natively-threaded interpreters (Rubinius2), Armstrong provides true concurrency and high stability, by design.

Timeout.timeout replacement that uses only 1 thread

Parallel TCP Server library. This is easy to make Multi-Process / Multi-Thread server

A threaded and preforked rack app server written in pure ruby

Simple, thread-based, light-weight cron implementation.

Celluloid based multi-threaded promise implementation

Dolphin: deploy agilely like dolphins can swim. A multi-threaded multi-stage deployment tool utilizes the full power of Git and Ruby.

A generic Ruby state machine pattern, with thread safety as a top priority.Make your object a hegemon, in complete control of its states.

Puma is a simple, fast, threaded, and highly concurrent HTTP 1.1 server for Ruby/Rack applications. Puma is intended for use in both development and production environments. It's great for highly concurrent Ruby implementations such as Rubinius and JRuby as well as as providing process worker support to support CRuby well.

Collect same jobs to single worker, reduce job number and improve thread utilization.

simple, threaded rack handler (webserver)

Provides methods to declare and use ThreadLocalVar instance variables

Trinidad background worker extension built upon JRuby-Rack-Worker which provides threaded workers along side your (JRuby-Rack) application. Includes (thread-safe) out-of-the-box implementations for popular worker libraries such as Resque and Delayed::Job but customized 'daemon' scripts can be used as well.

:title: The Ruby API :section: PYAPNS::Client There's python in my ruby! This is a class used to send notifications, provision applications and retrieve feedback using the Apple Push Notification Service. PYAPNS is a multi-application APS provider, meaning it is possible to send notifications to any number of different applications from the same application and same server. It is also possible to scale the client to any number of processes and servers, simply balanced behind a simple web proxy. It may seem like overkill for such a bare interface - after all, the APS service is rather simplistic. However, PYAPNS takes no shortcuts when it comes to completeness/compliance with the APNS protocol and allows the user many optimization and scaling vectors not possible with other libraries. No bandwidth is wasted, connections are persistent and the server is asynchronous therefore notifications are delivered immediately. PYAPNS takes after the design of 3rd party push notification service that charge a fee each time you push a notification, and charge extra for so-called 'premium' service which supposedly gives you quicker access to the APS servers. However, PYAPNS is free, as in beer and offers more scaling opportunities without the financial draw. :section: Provisioning To add your app to the PYAPNS server, it must be `provisioned` at least once. Normally this is done once upon the start-up of your application, be it a web service, desktop application or whatever... It must be done at least once to the server you're connecting to. Multiple instances of PYAPNS will have to have their applications provisioned individually. To provision an application manually use the `PYAPNS::Client#provision` method. require 'pyapns' client = PYAPNS::Client.configure client.provision :app_id => 'cf', :cert => '/home/ss/cert.pem', :env => 'sandbox', :timeout => 15 This basically says "add an app reference named 'cf' to the server and start a connection using the certification, and if it can't within 15 seconds, raise a `PYAPNS::TimeoutException` That's all it takes to get started. Of course, this can be done automatically by using PYAPNS::ClientConfiguration middleware. `PYAPNS::Client` is a singleton class that is configured using the class method `PYAPNS::Client#configure`. It is sensibly configured by default, but can be customized by specifying a hash See the docs on `PYAPNS::ClientConfiguration` for a list of available configuration parameters (some of these are important, and you can specify initial applications) to be configured by default. :section: Sending Notifications Once your client is configured, and application provisioned (again, these should be taken care of before you write notification code) you can begin sending notifications to users. If you're wondering how to acquire a notification token, you've come to the wrong place... I recommend using google. However, if you want to send hundreds of millions of notifications to users, here's how it's done, one at a time... The `PYAPNS::Client#notify` is a sort of polymorphic method which can notify any number of devices at a time. It's basic form is as follows: client.notify 'cf', 'long ass app token', {:aps=> {:alert => 'hello?'}} However, as stated before, it is sort of polymorphic: client.notify 'cf', ['token', 'token2', 'token3'], [alert, alert2, alert3] client.notify :app_id => 'cf', :tokens => 'mah token', :notifications => alertHash client.notify 'cf', 'token', PYAPNS::Notification('hello tits!') As you can see, the method accepts paralell arrays of tokens and notifications meaning any number of notifications can be sent at once. Hashes will be automatically converted to `PYAPNS::Notification` objects so they can be optimized for the wire (nil values removed, etc...), and you can pass `PYAPNS::Notification` objects directly if you wish. :section: Retrieving Feedback The APS service offers a feedback functionality that allows application servers to retrieve a list of device tokens it deems to be no longer in use, and the time it thinks they stopped being useful (the user uninstalled your app, better luck next time...) Sounds pretty straight forward, and it is. Apple recommends you do this at least once an hour. PYAPNS will return a list of 2-element lists with the date and the token: feedbacks = client.feedback 'cf' :section: Asynchronous Calls PYAPNS::Client will, by default, perform no funny stuff and operate entirely within the calling thread. This means that certain applications may hang when, say, sending a notification, if only for a fraction of a second. Obviously not a desirable trait, all `provision`, `feedback` and `notify` methods also take a block, which indicates to the method you want to call PYAPNS asynchronously, and it will be done so handily in another thread, calling back your block with a single argument when finished. Note that `notify` and `provision` return absolutely nothing (nil, for you rub--wait you are ruby developers!). It is probably wise to always use this form of operation so your calling thread is never blocked (especially important in UI-driven apps and asynchronous servers) Just pass a block to provision/notify/feedback like so: PYAPNS::Client.instance.feedback do |feedbacks| feedbacks.each { |f| trim_token f } end :section: PYAPNS::ClientConfiguration A middleware class to make `PYAPNS::Client` easy to use in web contexts Automates configuration of the client in Rack environments using a simple confiuration middleware. To use `PYAPNS::Client` in Rack environments with the least code possible `use PYAPNS::ClientConfiguration` (no, really, in some cases, that's all you need!) middleware with an optional hash specifying the client variables. Options are as follows: use PYAPNS::ClientConfiguration( :host => 'http://localhost/' :port => 7077, :initial => [{ :app_id => 'myapp', :cert => '/home/myuser/apps/myapp/cert.pem', :env => 'sandbox', :timeout => 15 }]) Where the configuration variables are defined: :host String the host where the server can be found :port Number the port to which the client should connect :initial Array OPTIONAL - an array of INITIAL hashes INITIAL HASHES: :app_id String the id used to send messages with this certification can be a totally arbitrary value :cert String a path to the certification or the certification file as a string :env String the environment to connect to apple with, always either 'sandbox' or 'production' :timoeut Number The timeout for the server to use when connecting to the apple servers :section: PYAPNS::Notification An APNS Notification You can construct notification objects ahead of time by using this class. However unnecessary, it allows you to programmatically generate a Notification like so: note = PYAPNS::Notification.new 'alert text', 9, 'flynn.caf', {:extra => 'guid'} -- or -- note = PYAPNS::Notification.new 'alert text' These can be passed to `PYAPNS::Client#notify` the same as hashes

A code frame to have an orderly use of thread and separate runtime and actual job of a Ruby class

A thread-pool for Ruby that supports joining, status-checking, stopping jobs and more.

Easily Checking http status with Multi-threaded

Runs Resque workers, threaded, within the Trinidad application server

A thread safe, Redis backed queue with the ability to delay items from being dequeued

This is a library to facilitate with the execution of work on parallel threads.

This is a beanstalk-based job-queueing-manager, replacement for gem 'stalker' with additions: 1. jobs grouping 2. jobs threading and forking 3. logging 4. background run (as daemon) 5. stalker makes to include full gem in application, but needed only client-side This is a client-side gem. For a worker you need * http://github.com/GearHead90/beanworker