From: Ricardo Panaggio Date: 2010-07-26T07:18:20+09:00 Subject: [ruby-core:31479] Re: [rubysoc] Semaphore implementation On Wed, Jul 21, 2010 at 22:30, Ricardo Panaggio wrote: > Hello, > > This time I was working on Semaphore. It's on my semaphore branch > (http://github.com/panaggio/ruby/compare/queue...semaphore#files_bucket > although github is not comparing them correctly =/) > > I'd like some feedback on the ruby implementation > (http://github.com/panaggio/ruby/compare/panaggio:queue...semaphore#diff-3) > and on the tests > (http://github.com/panaggio/ruby/compare/panaggio:queue...semaphore#diff-4). > > Now I'm solving a lot of annoying bugs (racing conditions are horrible > to debug and solve =/) and polishing the code, but I know there's need > to more features, like Semaphore#broadcast and Semaphore#try_wait, > that I'll implement soon. But I need to know it there's anything more > missing, or anything that could be just removed (like num_waiting). > > I don't think these tests can help me find problems on the code, but I > couldn't think about anything better. Any insight here you be very > appreciated. > > This feedback will also help me a lot to implement it in C, as I'll > have a list of features and a direction to go to. I'll continue the C > implementation as soon as I can have the ruby implementation as a > reference (just to have something to test against - I'll try to > implement it in C using as much native code as possible). > > There's some C code there (thread*), but it's very raw by now. Caleb > have told me about a lot of conceptual and implementation mistakes I > did, specially on thread_win32.c, and I know that there may be a lot > more. Any advice in here (if possible - I know it's a horrible code by > now) �will be also appreciated. Semaphore code is ready, both ruby and C code. Is there any issue? Any improvements? Again, should I create a single ticket for both implementations? As always, thanks a lot for all the help! > > Again, thanks in advance for all the help. You all gave me a lot of > good insights �last time I asked. > > Ricardo Panaggio > >