From owner-freebsd-java Wed Mar 20 15:35:47 2002 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by hub.freebsd.org (Postfix) with ESMTP id CA1C937B490 for ; Wed, 20 Mar 2002 15:33:43 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.35 #1 (Debian)) id 16npZl-00015O-00; Wed, 20 Mar 2002 15:33:01 -0800 Date: Wed, 20 Mar 2002 15:33:01 -0800 To: Nate Williams Cc: Richard Tobin , java@FreeBSD.ORG Subject: Re: Mozilla core... & HotSpot update Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15512.61557.26582.852492@caddis.yogotech.com> User-Agent: Mutt/1.3.27i From: Bill Huey 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 On Wed, Mar 20, 2002 at 01:26:29PM -0700, Nate Williams wrote: > 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 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.) 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. 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. The basic thing here is to handle the delivery of a SIGUSR1 to a thread in a syscall, interrupt the current operation and report that event/happening in methodical way so that's it is known to the language runtime... > If you're taking about asynchronous IO, all if the details are in the > green threads code, and/or the libc_r code. There are many ways of > dealing with them, and it's not too difficult to figure it out once you > get the hang of it. The bear is making sure you handle *ALL* the corner > cases. :( I'm going to start looking at that pretty soon after I finish with reviewing what I've done so far and answer various questions about safe-points and exceptions that are indeterminant in my mind. It's pretty wacky stuff. > > [CPU/architecture specifics] > > > > 3) Safe-point handling that deals with exceptions thrown in the middle of > > a JIT block still needs to be fully understood and verified. The call back > > framework during SIGUSR1 supporting the manipulation of ucontext_t's > > is now done. That supports the safe-point system. > > > > 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. 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 ? ;-) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message