home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: peter@ferranti.com (peter da silva)
-
- In article <1992Feb26.225630.1375@uunet.uu.net> henry@zoo.toronto.edu (Henry Spencer) writes:
- > The point is, the user gets access to the functionality by using threads.
-
- Well, ignoring quality of implementation issues... yes.
-
- > There is no gain to him in having another interface documented, especially
- > if it is one that might or might not be present, and especially if -- as
- > with non-blocking syscalls -- it leads to messier and buggier code
- > than the interface that is already provided.
-
- Well, actually, there is... if he's working in an environment that does not
- readily lead itself to coding his program in terms of threads. For example,
- if he's using an X toolkit or other non-reentrant library. In this case your
- threads program is going to have to end up having one master thread that does
- all the I/O, and a bunch of little threads running around it that emulate a
- non-blocking syscall interface.
-
- I understand your opinion of X, and I agree with it, but unfortunately it's
- a reality, and its requirement that user application programs provide
- reasonably good realtime response makes it a likely place to be doing
- this sort of thing.
-
- Also, a properly designed threads interface (I don't know if the 1003.4 one
- is in a "properly designed" state or not this week) doesn't expose details
- like whether the threads are managed in user mode or at the kernel level.
-
- > (Every non-blocking-calls
- > program I've ever seen has had a threads program inside, screaming to
- > get out.)
-
- How many have you seen? I've seen a lot, and some are simply written under
- constraints that make threads unattractive in the extreme.
-
- --
- -- Peter da Silva, Ferranti International Controls Corporation
- -- Sugar Land, TX 77487-5012; +1 713 274 5180
- -- "Have you hugged your wolf today?"
-
-
- Volume-Number: Volume 27, Number 21
-
-