diff options
| author | Eli Zaretskii | 2015-11-03 18:17:06 +0200 |
|---|---|---|
| committer | Eli Zaretskii | 2015-11-03 18:17:06 +0200 |
| commit | e7bde34e939451d87fb42a36195086bdbe48b5e1 (patch) | |
| tree | f0f2d8396a187740aeaa4706f8cdb84f81722418 | |
| parent | 470e3028d8a741d97349faa8fdeb148d913a49d0 (diff) | |
| download | emacs-old-branches/concurrency.tar.gz emacs-old-branches/concurrency.zip | |
; * src/systhread.c [WINDOWSNT]: Fix typos in comments.old-branches/concurrency
| -rw-r--r-- | src/systhread.c | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/src/systhread.c b/src/systhread.c index bde0f027e78..c11e0247886 100644 --- a/src/systhread.c +++ b/src/systhread.c | |||
| @@ -207,7 +207,7 @@ uintptr_t _beginthread (void (__cdecl *)(void *), unsigned, void *); | |||
| 207 | 207 | ||
| 208 | /* Mutexes are implemented as critical sections, because they are | 208 | /* Mutexes are implemented as critical sections, because they are |
| 209 | faster than Windows mutex objects (implemented in userspace), and | 209 | faster than Windows mutex objects (implemented in userspace), and |
| 210 | satisfy the requirements, since we only needto synchronize within a | 210 | satisfy the requirements, since we only need to synchronize within a |
| 211 | single process. */ | 211 | single process. */ |
| 212 | void | 212 | void |
| 213 | sys_mutex_init (sys_mutex_t *mutex) | 213 | sys_mutex_init (sys_mutex_t *mutex) |
| @@ -234,7 +234,7 @@ sys_mutex_destroy (sys_mutex_t *mutex) | |||
| 234 | { | 234 | { |
| 235 | /* FIXME: According to MSDN, deleting a critical session that is | 235 | /* FIXME: According to MSDN, deleting a critical session that is |
| 236 | owned by a thread leaves the other threads waiting for the | 236 | owned by a thread leaves the other threads waiting for the |
| 237 | critical session in an undefined state. Posix docs seems to say | 237 | critical session in an undefined state. Posix docs seem to say |
| 238 | the same about pthread_mutex_destroy. Do we need to protect | 238 | the same about pthread_mutex_destroy. Do we need to protect |
| 239 | against such calamities? */ | 239 | against such calamities? */ |
| 240 | DeleteCriticalSection ((LPCRITICAL_SECTION)mutex); | 240 | DeleteCriticalSection ((LPCRITICAL_SECTION)mutex); |
| @@ -354,6 +354,8 @@ sys_thread_equal (sys_thread_t one, sys_thread_t two) | |||
| 354 | 354 | ||
| 355 | static thread_creation_function *thread_start_address; | 355 | static thread_creation_function *thread_start_address; |
| 356 | 356 | ||
| 357 | /* _beginthread wants a void function, while we are passed a function | ||
| 358 | that returns a pointer. So we use a wrapper. */ | ||
| 357 | static void | 359 | static void |
| 358 | w32_beginthread_wrapper (void *arg) | 360 | w32_beginthread_wrapper (void *arg) |
| 359 | { | 361 | { |
| @@ -369,12 +371,10 @@ sys_thread_create (sys_thread_t *thread_ptr, const char *name, | |||
| 369 | the main program. On GNU/Linux, it seems like the stack is 2MB | 371 | the main program. On GNU/Linux, it seems like the stack is 2MB |
| 370 | by default, overridden by RLIMIT_STACK at program start time. | 372 | by default, overridden by RLIMIT_STACK at program start time. |
| 371 | Not sure what to do with this. See also the comment in | 373 | Not sure what to do with this. See also the comment in |
| 372 | w32proc"new_child. */ | 374 | w32proc.c:new_child. */ |
| 373 | const unsigned stack_size = 0; | 375 | const unsigned stack_size = 0; |
| 374 | uintptr_t thandle; | 376 | uintptr_t thandle; |
| 375 | 377 | ||
| 376 | /* _beginthread wants a void function, while we are passed a | ||
| 377 | function that returns a pointer. So we use a wrapper. */ | ||
| 378 | thread_start_address = func; | 378 | thread_start_address = func; |
| 379 | 379 | ||
| 380 | /* We use _beginthread rather than CreateThread because the former | 380 | /* We use _beginthread rather than CreateThread because the former |