about summary refs log tree commit diff
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
glibc-bcd249f6382acf5ada63e834242e9fb13bea7e4b.tar.xz
glibc-bcd249f6382acf5ada63e834242e9fb13bea7e4b.zip
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