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 conne
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
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
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
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
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
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 i
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
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-sav
Nate Lawson wrote:
> > It's not so much that I volunteered as I said that I'd help with
> > thread/proc issues..
> > The trouble was that there are places where it used a proc in the old
> > code, but in some cases it needs to be a proc, and in other cases it now
> > needs to be a thread. But all t
10 matches
Mail list logo
