Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Nov 2002 01:51:41 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        Nate Lawson <nate@root.org>, current@FreeBSD.ORG
Subject:   Re: [PATCH] Searching for users of netncp and nwfs to help
Message-ID:  <3DE495AD.6C73EF3D@mindspring.com>
References:  <200211270742.XAA57750@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 schedlock. Certainly never store it
> anywhere.. Particularly anywhere that may persist while you sleep in any
> way.   -exception.. kernel threads- .. they are persistant.

The received lock response is going to come in on IPX, which is
like UDP, so it's connectionless.  The NCP is an el-cheapo
timeout-and-retransmit layer on top of formated IPX datagrams
(NetWare runs on IPX, not SPX).  Basically, this means that the
response and the async response to a lock requests, or the
async server-to-client notifications (shutdowns, etc.) can
come in and activate any listener.  The connection has to be
looked up, and then the operation has to be processed in the
context of the process that has the connection open.  It does
not care which thread it's processed on, only that it's in the
process that owns the connection (there are address space issues).

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 connection, when there is one request outstanding.

The only exception isn't really relevent here, because the code
that I've seen writen doesn't really support "packet burst"
mode data transfers (pseudo-windowed data streams layered on
top of datagrams).

Basically, this means unless someone is willing to do the work
to set up a virtual circuit -- three network handles per -- per
each potentially outstanding thread, and then, further, maintain
an "idle pool" for them, everyone should treat the code as if it
were not thread reentrant... because it's not.

Gary Tomlinson, Duck, Ted Cowan, and others literally put man
years into getting that working, and they had access to Novell
source code in order to do the work in the NUC (NetWare UNIX
Client) product.  It's unlikely that it can be reverse-engineered
without at least a PNW/NWU (Portable NetWare/NetWare for UNIX)
source license.

The *only* reasons there's a thread in there now as a paremeter
is that (1) the top level interfaces require it and (2) the
lockmgr() calls, that shouldn't need to be there, IMO, require
it as a parameter.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE495AD.6C73EF3D>