maverick@Portia.Stanford.EDU (Steve Whitney) (11/22/88)
I have read that GEM system calls are not reentrant so they can't be
called from interrupts and no one can kludge up a multitasking GEM
a la MT C Shell without practically rewriting them. What I'd like
to know is
1) Is this true?
2) Would it be possible to rewrite them as reentrant (of course, you'd
have to semaphore the BLiTTER since it isn't reentrant)?
3) Would it be possible to write a scheduler of some sort to sit at
the TRAP #2 vector and figure out which process to run with some
kind of Juggler like interface to switch the menu bars?
Just food for thought.
--Steve
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steve Whitney Internet: maverick@portia.stanford.edu
UUCP: ..!decwrl!portia.stanford.edu!maverick
No room for a quote Bitnet: maverick%portia.stanford.edu@stanford
GEnie: S.WHITNEYdavid@bdt.UUCP (David Beckemeyer) (11/23/88)
In article <4186@Portia.Stanford.EDU> maverick@Portia.Stanford.EDU (Steve Whitney) asks: >3) Would it be possible to write a scheduler of some sort to sit at > the TRAP #2 vector and figure out which process to run with some > kind of Juggler like interface to switch the menu bars? It's possible - but it's probably more work than you had in mind. You could hack this forever trying to get it to work reliably. And in the long run it would be less work to simply re-write it. I looked long and hard into adding a multiiasking layer to GEM. I even got some preliminary stuff implemented, along the lines Steve mentions above - switching menus when the application is topped. It's a big job. The current GEM stuff isn't ready for multitasking. Also many programs that look like GEM programs really cheat like heck. This is why the author of Juggler had to re-write the switching technique becuase so few GEM programs were "true" well-behaved GEM programs. I doubt if this is going to change in the future. This makes it very dificult to implement the ideal "super-system" where GEM is provided as a sub-component of a real multitasking windowing system. You'd also have to write a new desktop since the standard one doesn't know anything about multitasking. Summary: it would be a lot of work to do it right. And it would be even more work to try and hack in a "switcher" trap #2 handler that really works. -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ