-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semaphore #4
base: master
Are you sure you want to change the base?
Semaphore #4
Conversation
Hi Luis. Looks like a cool feature. For now I'd prefer for you to maintain this as a separate fork as I'm not prepared to maintain it in the future. A few questions... Are you running this in production? If so, how much traffic is it receiving? |
Hi Chad, I'm happy to keep it as a fork. I'll be running this in production in a couple of months so I don't know yet how much traffic it will receive. The reason I needed this is that my main application has to be able be able to make 10 connections to a resource. Each connection has to have a Mutex and the whole process also has to be Mutex. So to avoid having to use 10 + 1 mutexes it's easier to use a semaphore. Cheers, Luis On Aug 16, 2012, at 1:24 PM, Chad Remesch wrote:
|
Hi Luis, I think I understand your use case and I'm happy to hear you were able to solve your problem by modifying Officer. Please keep me in the loop about how your changes work in production. I find it to be the best test of new code :-) -Chad |
Hey Chad, I needed a semaphore server in stead of a Mutex server. So I took your officer gem and modified it to support n semaphores. I made it backwards compatible so all the tests still pass. There's just the option to add a lock size to the name (with a # i.e. my_lock#2) to create a 2 semaphore.
Thanks for all the good work on Officer.
Cheers, Luis