Date: Wed, 20 Mar 2002 15:33:01 -0800 From: Bill Huey <billh@gnuppy.monkey.org> To: Nate Williams <nate@yogotech.com> Cc: Richard Tobin <richard@cogsci.ed.ac.uk>, java@FreeBSD.ORG Subject: Re: Mozilla core... & HotSpot update Message-ID: <20020320233301.GA4011@gnuppy.monkey.org> In-Reply-To: <15512.61557.26582.852492@caddis.yogotech.com> References: <200203201509.PAA29782@sorley.cogsci.ed.ac.uk> <20020320201858.GA3125@gnuppy.monkey.org> <15512.61557.26582.852492@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020320233301.GA4011>