aboutsummaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ54
1 files changed, 27 insertions, 27 deletions
diff --git a/FAQ b/FAQ
index 1a21ffd..4198a87 100644
--- a/FAQ
+++ b/FAQ
@@ -560,11 +560,11 @@ newer.
1.20. Which tools should I use for MIPS?
-{AJ} You should use the current development version of gcc 2.97 from CVS.
-gcc 2.95.x does not work correctly on mips-linux.
+{AJ} You should use the current development version of gcc 3.0 or newer from
+CVS. gcc 2.95.x does not work correctly on mips-linux.
-You need also recent binutils, anything before and including 2.10 will not
-work correctly. Either try the Linux binutils 2.10.0.33 from HJ Lu or the
+You need also recent binutils, anything before and including 2.11 will not
+work correctly. Either try the Linux binutils 2.11.90.0.5 from HJ Lu or the
current development version of binutils from CVS.
Please note that `make check' might fail for a number of the math tests
@@ -1862,29 +1862,29 @@ this should be necessary.
supports synchronous context switches only. There are several reasons for
this:
- o UNIX provides no other (portable) way of effecting a synchronous
- context switch (also known as co-routine switch). Some versions
- support this via setjmp()/longjmp() but this does not work
- universally.
-
- o As defined by the UNIX '98 standard, the only way setcontext()
- could trigger an asychronous context switch is if this function
- were invoked on the ucontext_t pointer passed as the third argument
- to a signal handler. But according to draft 5, XPG6, XBD 2.4.3,
- setcontext() is not among the set of routines that may be called
- from a signal handler.
-
- o If setcontext() were to be used for asynchronous context switches,
- all kinds of synchronization and re-entrancy issues could arise and
- these problems have already been solved by real multi-threading
- libraries (e.g., POSIX threads or Linux threads).
-
- o Synchronous context switching can be implemented entirely in
- user-level and less state needs to be saved/restored than for an
- asynchronous context switch. It is therefore useful to distinguish
- between the two types of context switches. Indeed, some
- application vendors are known to use setcontext() to implement
- co-routines on top of normal (heavier-weight) pre-emptable threads.
+- UNIX provides no other (portable) way of effecting a synchronous
+ context switch (also known as co-routine switch). Some versions
+ support this via setjmp()/longjmp() but this does not work
+ universally.
+
+- As defined by the UNIX '98 standard, the only way setcontext()
+ could trigger an asychronous context switch is if this function
+ were invoked on the ucontext_t pointer passed as the third argument
+ to a signal handler. But according to draft 5, XPG6, XBD 2.4.3,
+ setcontext() is not among the set of routines that may be called
+ from a signal handler.
+
+- If setcontext() were to be used for asynchronous context switches,
+ all kinds of synchronization and re-entrancy issues could arise and
+ these problems have already been solved by real multi-threading
+ libraries (e.g., POSIX threads or Linux threads).
+
+- Synchronous context switching can be implemented entirely in
+ user-level and less state needs to be saved/restored than for an
+ asynchronous context switch. It is therefore useful to distinguish
+ between the two types of context switches. Indeed, some
+ application vendors are known to use setcontext() to implement
+ co-routines on top of normal (heavier-weight) pre-emptable threads.
It should be noted that if someone was dead-bent on using setcontext()
on the third arg of a signal handler, then IA-64 Linux could support