Date: Wed, 20 Mar 2002 16:01:45 -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: <20020321000145.GA4319@gnuppy.monkey.org> In-Reply-To: <15513.7648.287464.414451@caddis.yogotech.com> 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> <15513.7648.287464.414451@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 20, 2002 at 04:40:16PM -0700, Nate Williams wrote: > 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!) It's SYSV behavior, not sure about Linux. > > 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? I think that OS X is missing some pthreads features that deal with per thread signal delivery. I'm not sure though. They might just use a Machism of some sort. I could ask a Darwin person if you want ? Darwin is rather antiquated about signal delivery (lacking the Posix prototype for signal handlers) and threads. > > 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. Right, the BSD behavior prevents this, which might be a problem for implementing interruptable IO. The Linux code just omits that stuff completely. > > 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. I know. I'm wonder if I should mess with this at all right now. You definitely gave me some clarity on this issue. > How about making diffs available for folks to review? I might as well commit it if that's the case. > > 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. :) Yes, thanks. I've been pretty isolated doing this stuff and the topic of JIT compilers are rather obscure so I don't really have a clique of folks to yack with constantly about these issues. It doens't help to be working in a bleeding edge code tree from a research project at Stanford (Self) either. :-) 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?20020321000145.GA4319>