From owner-freebsd-java Wed Mar 20 15:41:29 2002 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 9782D37B400 for ; Wed, 20 Mar 2002 15:40:43 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA04314; Wed, 20 Mar 2002 16:40:16 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g2KNeGv01893; Wed, 20 Mar 2002 16:40:16 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15513.7648.287464.414451@caddis.yogotech.com> Date: Wed, 20 Mar 2002 16:40:16 -0700 To: Bill Huey Cc: Nate Williams , Richard Tobin , java@FreeBSD.ORG Subject: Re: Mozilla core... & HotSpot update In-Reply-To: <20020320233301.GA4011@gnuppy.monkey.org> References: <200203201509.PAA29782@sorley.cogsci.ed.ac.uk> <20020320201858.GA3125@gnuppy.monkey.org> <15512.61557.26582.852492@caddis.yogotech.com> <20020320233301.GA4011@gnuppy.monkey.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Define what you mean by 'interruptible' IO? Do you mean select/poll, or > > asynchronous IO? I don't believe BSD allows one to 'interrupt' an IO > > system call, so I'm not sure what you're asking. > > I already know that BSDs don't do that after reading a faq on glibc. I wasn't aware that Linux/Solaris allow interrupting IO syscalls (especially Linux). Does M$ also allow one to interrupt syscalls? (This is news to me!) > I was looking for the definition of UESP verses ESP on x86 > architectures under Solaris and Linux at that time. (UESP is a machine > pseudo register to simulate and exception stack I'm assuming. Please > correct me if I'm wrong.) I know nothing about Linux, and very little about Solaris. > The current interruptable IO wrapper is a macro that has a jmpbuf > which loops back before the IO syscall when a SIGUSR1 is delivered to > it and then used it to return an OS_INTRPT, when the syscall block > reexecuted. This kind of thing doesn't sound portable at all. I wonder how OS-X does things? > It's kind of funny way of dealing with EINTRs and I suspect that they did > that to avoid dealing with syscall return value specifics. I'm not sure > how valid that is for FreeBSD. I wonder if I can do something else to get > around using this rather hackish macro and if the return valids of those > functions would be sufficient for reporting interrupts thrown by a Unix > signal. That's currently under examination. It seems to me that it's not even necessary, since syscalls can't be interrupted, you have nothing to handle. Unless I'm misunderstanding what you're saying. > The basic thing here is to handle the delivery of a SIGUSR1 to a > thread in a syscall See above. You can't interrupt an IO syscall in BSDs. However, that may change in 5.0, but that's a ways off, so it may end up being a 6.0 feature. > > > This section is almost complete after the work I've done over the last > > > couple of days. > > > > And where is that work, pray tell? > > On my local machine ? you want it commited ? It's pretty sloppy at > this time. How about making diffs available for folks to review? > I'm done with the machine aspects of this section, but I need to verify how > the rest of the supporting functions and the higher level calling functions > use this stuff in a conceptually clear way. The potential problems could be > subtle and I want to fully understand this so that I can track bugs down > effectively. As you know, this is an insanely complicated and large system. > > In my opinion, prevention is better than a brute force search of potential > bugs in case like this. Maybe I'm being overall cautious about this, eh ? I don't think it's possible to be too cautious at this point. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message