Hi, Only, I'm stumped, what does 1b8881d726d96d4dacd554c3b3e2f7b4c4012a68 do? The commit log implies it's important...but the patch it's-self is cryptic. Cheers -- Alexander Clouter .sigmonster says: Fundamentally, there may be no basis for anything.
Alexander Clouter wrote:
Only, I'm stumped, what does 1b8881d726d96d4dacd554c3b3e2f7b4c4012a68 do? The commit log implies it's important...but the patch it's-self is cryptic.
There's a commit 1b888... ? Not in any repository I have access to. You're probably looking at a local branch. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Alexander Clouter wrote:
Only, I'm stumped, what does 1b8881d726d96d4dacd554c3b3e2f7b4c4012a68 do? The commit log implies it's important...but the patch it's-self is cryptic.
There's a commit 1b888... ?
Meant this one: http://github.com/alandekok/freeradius-server/commit/1fef8c64bf31668808bb9c2...
Not in any repository I have access to. You're probably looking at a local branch.
Right, for some reason my clone has gotten borked somehow as when I look at event.c after the patch is applied I have: ---- static void no_response_to_proxied_request(void *ctx) { [snipped] check_for_zombie_home_server(request); home = request->home_server; home = request->home_server; [snipped] } ---- Yeah, that duplication is not a mistype :-/ /me goes to hit his branch with a monkey wrench Cheers -- Alexander Clouter .sigmonster says: Never trust a child farther than you can throw it.
Alexander Clouter wrote:
Meant this one:
http://github.com/alandekok/freeradius-server/commit/1fef8c64bf31668808bb9c2...
Ah. That's deep magic. :) In order to avoid mutex locks where possible, the "request" pointers magically become invalid after a request has been proxied. Referencing them after a "proxy_listener->send" call will result in crashes. Why? Thread race conditions. thread 1) send proxied request packet thread 2) receive response thread 2) muck around with request thread 1) access request server) Boom! Thread programming isn't hard if you have a twisted mind. The alternative is for every "request" to have a mutex associated with it. Threads lock the mutex when they're access the request, which prevents any other thread from mucking with it. This is also a lot more expensive, and (IMHO) complicated. Alan DeKok.
participants (2)
-
Alan DeKok -
Alexander Clouter