Julian Elischer wrote: > > The answer is that "the code doesn't care what thread"; it would > > prefer to not have to think in terms of threads at all, but if > > you want to force it to, then it's going to think in terms of > > "blocking contexts for the benefit of FreeBSD code it calls", > > and nothing else. > > Hense the confusion as to whether to use a thread or a proc..
Not confusing at all. The only issue is references to the connection structure caches proc, which uses the first thread on the cached proc; otherwise, it uses the thread that was passed in. > > Did you want me to update the patch to use your FIRST_THREAD_IN_PROC > > macro and resend it? > > you could but the fact that FIRST_THREAD_IN_PROC() is used indicates > that the whole thing is broken anyway. Your edits are mostly mechanical > and don't actually solve the problem. To do that you probably need > to actually rewrite some of it I think. They were _intended_ to be mechanical edits. It fixes the problem for the people who were willing to fix it, but didn't have any idea of how to do the edits. I can't really rewrite the code for you, without risking that Novell would claim that I did it with knowledge of the NUC implementation... you _do_ remember the last time Novell and BSD had an issue over code, right, back in 1994, after they bought USL? It's probably better that the patch I've done get to the people who volunteered to fix the code, once it could be compiled, and that the people who volunteered to help them with the threads issues do so. I've done as much as I can without legal risk. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
