-
Notifications
You must be signed in to change notification settings - Fork 548
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
feature: out of band requests #67
Conversation
BTW, starting standalone without the PASSENGER_DEBUG set,
|
Yep, the Passenger Standalone bug is a different one which I'll fix seperately. I'm mostly done with the enable/disable process stuff. Could you rebase your patch against HEAD? |
} | ||
unique_lock<boost::mutex> lock(pool->syncher); | ||
pool = getPool(); | ||
if (OXT_UNLIKELY(pool == NULL)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a nasty race condition in my code today, and I see you're suffering from it too. You should change this check here to: OXT_UNLIKELY(pool == NULL || process->detached())
Thanks ... back on this again today. |
While working on the above feedback, I noticed two problems with master, In attach(), where the same process could be in the disableWaitlist ... however, the first waiter for some process to call addProcessToList changes the enabled state of that process. This causes further waiters for that same process to fall into the else clause. In onSessionClose(), you have, removeProcessFromList(process, disablingProcesses);
addProcessToList(process, enabledProcesses);
removeFromDisableWaitlist(process, DR_SUCCESS, actions); where I think you meant, removeProcessFromList(process, disablingProcesses);
addProcessToList(process, **disabledProcesses**);
removeFromDisableWaitlist(process, DR_SUCCESS, actions); |
with || process->detached()
Ah yes, that code in onSessionClose() was a typo. I've fixed that in the bugfixes I committed this weekend. I don't understand your comment about attach(). You're only supposed to call attach() on a process that isn't yet in the Group, so it couldn't possibly be in the disableWaitlist. |
I don't mean that the process being attached is in the disableWaitlist, but rather the disableWaitlist may contain multiple waiters and some of those waiters may point to the same process. So this snippet,
should be more like this,
|
Thanks. I've merged your patches with a few minor changes. |
Everything's looking good so far. If no unexpected problems are found this will be part of beta 2. How did you like contributing to Passenger 4's codebase? Is all the code clearly understandable, readable, etc? |
Awesome! First, I really appreciate the code base having tests (cxx, ruby, integration). I feel much more confident making changes knowing that all the existing tests still pass. Second, c++ is not my primary language these days and I appreciate your help and patience. I was able to read through the code and figure out the places I needed to modify fairly quickly. There was enough comments and examples of similar looking code (i.e. spawning a thread, acquiring lock, passing calbacks) for me to piece together what I needed to do. The parts I had trouble with was mainly related to getting all the details of locking correct (e.g. process is not detached). I still think it would be good idea to invest some time into a macro or a function. |
continuing from #66
Let me know if / where you'd like me to add docs.