home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!pipex!warwick!uknet!acorn!steve
- From: steve@acorn.co.uk (Steve "daffy" Hunt)
- Newsgroups: comp.sys.acorn.advocacy
- Subject: Re: The ARM Club
- Message-ID: <20169@acorn.co.uk>
- Date: 16 Nov 92 12:29:28 GMT
- References: <2yL7LBj025n@khantazi.welly.gen.nz>
- Organization: Acorn Computers Limited, Cambridge, UK
- Lines: 34
- X-Newsreader: TIN [version 1.1 PL6]
-
- Philip R. Banks (banksie@khantazi.welly.gen.nz) wrote:
- : davism@uhura.aston.ac.uk (Mik Davis) writes:
- :
- : > About co-operative vs Pre-emtive multitasking...
- : >
- : > What would happen if someone were to try and come up with a system which had
- : > a RiscOS-like front end (i.e. co-operative) but which had a pre-emptive
- : > back-end for chucking jobs into the background or running a "batch" job?
- :
- : You get X windows basically. And I am less than impressed with the
- : responsiveness of X windows myself. (Very nice on the networking side
-
- This is not very accurate.
-
- X servers are not co-operative. Typical X servers are internally
- single-threaded and have a simple internal scheduler that handles
- operations from non-quiescent clients on a round-robin basis. X
- protocol operations are typically atomic, but that said, there is no
- way for an application to "hog" the server like a RISC OS program can
- hog the machine. In other words, XNextEvent is *not* the basis for
- scheduling (either in the X server or the client's OS) like Wimp_Poll
- is.
-
- Other clients that are not actually doing X operations at a particular
- time still run - they aren't blocked completely just because the X
- server is doing something for another client.
-
- Furthermore, there is nothing in the X protocol that forces X servers
- to be single-threaded and I believe that multithreaded X servers have
- been experimented with, and may exist on certain platforms.
-
- -- Steve
- --
- Steve Hunt steve@acorn.co.uk
-