On Tue, Nov 12, 2002 at 02:00:14AM +0100, Ulrich Weigand was heard to remark: > Linas Vepstas wrote: > > >-- if 'exception 04' can be caught and passed back up to the library, > > Unfortunately it can't, as key-protection violation is a 'terminating' > exception condition, which means the CPU state at the time the > interruption is delivered is undefined. This means that the instruction > that caused the exception might have already been *partially* executed, > but there's no way to find out whether and to what extent that happened.
Ugh. Well, that could stop the show. But since the instruction causing this would be a problem state instruction, maybe there are fewer wacky situations to deal with. Clearly, a store can be re-executed without harm, even if its been partly executed before. The problem would be with any instructions that had side effects, that would not do the same thing the second time around, as it did the first time. I don't know what these would be. > >Aside: In some varients, the access was per-thread. > > Now this is distincly weird ;-) I would imagine this made the Well, the graphics commands were not inherently atomic; they have to be serialized. To avoid race conditions, either you allowed only one thread to have direct access :-( or you forced the use of a lock, which was out of the question because of the performance hit, or you gave each thread its own graphics context. Technically, its not hard to implement this, but it drove traditional unix guys (and torvalds & alan cox) nuts. (Since we used page tables to enforce access, each thread would have slightly different page tables: one reason they hated it.) I've never heard of direct-hardware access to an ethernet card, but in principle, one could do it: then one could avoid things like the zero-copy technology much balyhooed in the Linux kernel, and could avoid having to put portions of a web server in the kernel (khttpd), since presumably, the application could now just blast bytes directly into the ethernet card. But if one did this, imagine the bad stuff that would happen if the app was allowed to have two threads to blast bytes into the card, and you didn't do something to control that situation. You could argue for "cooperative multi-threading" but that sure has the flavour of bad old msdos/mac/win. Damned if you do, damned if you don't. ---------------- anyway, to summarize: I still think that providing some mechanism to build a 'trust barrier' between app and library would be a very good tool to add to the programmer's toolkit, even if/when there are other ways to acheive the same effect. (By the same token, threads are "just processes with shared memory", and so therefore traditional unix should not support threads? But we do, and there are certain problem domains where they are just the right thing. Threads are not easy to use, and require some sophistication, but thier utility is undoubted these days.) --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
msg09415/pgp00000.pgp
Description: PGP signature
