Julian Elischer wrote:
Where does the passed in thread come from?
Your changes to make certain functions which are exported interfaces
take a thread * instead of a proc * argument.
Generally don't use a thread pointer other than yourself unless you have
a lock on the proc structure, or the
Terry Lambert wrote:
The main problem here is that lockmgr() is being called to lock
things that technically don't need to be locked, at all, really,
to insure that operations are not attempted concurrently. It's
not really necessary: the server will refuse additional requests
on a
Terry Lambert wrote:
I'll take a whack at it and send it out by tomorrow, working or not.
Don't bother. 8-).
The attached patch makes it compile, and takes a shot at doing the
right thing.
Just a followup... select definitely won't work (IMO), but needs
someone who is threads-savvy
some comments:
firstly:
ncp_conn_locklist(int flags, struct proc *p)
{
! struct thread *td = TAILQ_FIRST(p-p_threads); /* XXX
*/
!
! return lockmgr(listlock, flags | LK_CANRECURSE, 0, td);
}
can't you use unidifs? :-)
ok
there is a Macro to find the first thread
First of all, the patch was just to get to the point of compilability,
which other prople said they would take it from there. I don't
have a NetWare server to test against in my apartment. I'd be just as
happy to _let_ the other people who wanted to take it from there do
do, now that I made it
Terry Lambert wrote:
Did you want me to update the patch to use your FIRST_THREAD_IN_PROC
macro and resend it?
OK; here it is, whether you wanted it or not.
-- Terry
smbfs_thr.diff.gz
Description: GNU Zip compressed data
On Tue, 26 Nov 2002, Terry Lambert wrote:
Uh, how exactly is that less obnoxious, given it's the same code
with a different name and an obnoxious inline instead of a macro?
8-).
it's shorter ..
You can always get from a thread to a single process but the reverse
always presents
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.
debug5.0problems
In-Reply-To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 26 Nov 2002, Terry Lambert wrote:
Julian Elischer wrote:
The answer is that the code doesn't care what thread; it would
prefer to not have
