search for: conditionvariable

Hello all, I''ve come up w/ a worker class that manages queued jobs using a fixed number of child workers. Well, that''s not quite true -- a new worker is spawned for each job, but you set the total number that may exist at once. There are three components: 1) queue_worker.rb: The singleton worker that manages the child workers. You probably want to auto start this. Make sure you

Quick note! fastthread 0.6.3 has been released to address a minor compatibility issue with ConditionVariable -- as with the original thread.rb, ConditionVariable can now be used with any mutex class implementing Mutex''s public interface. As before, gem and tarball available from RubyForge courtesy of the Mongrel project: http://rubyforge.org/frs/?group_id=1306 -mental -------------- next part...

...esen > www.stellar-legends.de - Weltraum-Browsergame im Alpha-Stadium Hey Michael- Yeah I do have a beta here. It is working very well. What I did to make it easier to refactor was to grab an older version. One that didn''t have any of the Timing stuff or the Threading stuff for ConditionVariables and all that. Once I got it down to its basic format, I was able to write a nice ThreadPool class and then use that in the MiddleMan. So it is way cleaner now. the middleman holds a thread pool and does all the thread management so the workers don''t have to. It made the code small...

fastthread is a library which replaces the synchronization primitives defined in stdlib?s thread.rb (Mutex, ConditionVariable, Queue, and SizedQueue) with optimized versions which: * are much faster (in the non-contention case, speed comparable to direct use of Thread.critical or Thread.exclusive) * don?t leak memory (the stdlib implementation of Mutex manages to trigger worst-case behavior of...

...ate/terminate? to check, run cleanup code, and then raise the :safe_to_kill signal. def initialize(job_key, args={}) @logger = BACKGROUNDRB_LOGGER @thread = nil; @job_key = job_key @args = args end def start_process begin @thread = Thread.new do Thread.current[:safe_to_kill] = ConditionVariable.new Thread.current[:kill] = false do_work(@args) end rescue Exception => e @logger.error e.inspect end end def check_terminate raise "Somehow this worker doesn''t have a registered thread" if thread.nil? return @thread[:kill] end def terminate? t...

...00) at pthread_create.c:333 #9 0x00007f2178e83f6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 16 (Thread 0x7f2107fff700 (LWP 6600)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x00007f21751ea912 in base::ConditionVariable::TimedWait(base::TimeDelta const&) () from /lib64/libQt5WebEngineCore.so.5 #2 0x00007f21751eb1b5 in base::WaitableEvent::TimedWait(base::TimeDelta const&) () from /lib64/libQt5WebEngineCore.so.5 #3 0x00007f21751cce51 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () from /...

Well, just when I thought I was out of the fastthread business... Okay, in brief: fastthread is a Ruby extension which re-implements the primitives in Ruby''s thread.rb in C. It was merged into 1.8.6, replacing the old thread.rb implementation, but the version that was merged had a couple serious bugs. So -- now I release fastthread 1.0, which is basically the Ruby 1.8.6 version with

Heya Folks- This is mainly for Zed and Mentalguy. I have been playing with the new release of rubygems 0.9.0.8 and I have a major problem with the requirement that fastthread needs to be required before thread. Just requiring rubygems and then requiring fastthread right after that will throw the error: ez _blog $ ruby require ''rubygems'' require