summaryrefslogtreecommitdiff
path: root/FAQ.in
diff options
context:
space:
mode:
authorAndreas Jaeger <aj@suse.de>2001-05-05 14:43:14 +0000
committerAndreas Jaeger <aj@suse.de>2001-05-05 14:43:14 +0000
commitbcd249f6382acf5ada63e834242e9fb13bea7e4b (patch)
treed8e9e5eae04c081d26a9be83a00eda0d510dea2e /FAQ.in
parentaa2e3ec3866ea0cde49ceeb9d9d4ef741af2fea9 (diff)
downloadglibc-bcd249f6382acf5ada63e834242e9fb13bea7e4b.tar.gz
Stylistic changes to make HTML generation easier.
Diffstat (limited to 'FAQ.in')
-rw-r--r--FAQ.in46
1 files changed, 23 insertions, 23 deletions
diff --git a/FAQ.in b/FAQ.in
index 82d9be9506..7c2458780a 100644
--- a/FAQ.in
+++ b/FAQ.in
@@ -1602,29 +1602,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