Date: Wed, 20 Mar 2002 16:40:16 -0700 From: Nate Williams <nate@yogotech.com> To: Bill Huey <billh@gnuppy.monkey.org> Cc: Nate Williams <nate@yogotech.com>, Richard Tobin <richard@cogsci.ed.ac.uk>, java@FreeBSD.ORG Subject: Re: Mozilla core... & HotSpot update Message-ID: <15513.7648.287464.414451@caddis.yogotech.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15513.7648.287464.414451>