From owner-freebsd-current Wed Nov 27 1:53:16 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B6D837B401 for ; Wed, 27 Nov 2002 01:53:15 -0800 (PST) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9949B43EAF for ; Wed, 27 Nov 2002 01:53:14 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0035.cvx40-bradley.dialup.earthlink.net ([216.244.42.35] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18GysP-0004SJ-00; Wed, 27 Nov 2002 01:53:01 -0800 Message-ID: <3DE495AD.6C73EF3D@mindspring.com> Date: Wed, 27 Nov 2002 01:51:41 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Nate Lawson , current@FreeBSD.ORG Subject: Re: [PATCH] Searching for users of netncp and nwfs to help References: <200211270742.XAA57750@InterJet.elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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