/* Mutexes are implemented as critical sections, because they are
faster than Windows mutex objects (implemented in userspace), and
- satisfy the requirements, since we only needto synchronize within a
+ satisfy the requirements, since we only need to synchronize within a
single process. */
void
sys_mutex_init (sys_mutex_t *mutex)
{
/* FIXME: According to MSDN, deleting a critical session that is
owned by a thread leaves the other threads waiting for the
- critical session in an undefined state. Posix docs seems to say
+ critical session in an undefined state. Posix docs seem to say
the same about pthread_mutex_destroy. Do we need to protect
against such calamities? */
DeleteCriticalSection ((LPCRITICAL_SECTION)mutex);
static thread_creation_function *thread_start_address;
+/* _beginthread wants a void function, while we are passed a function
+ that returns a pointer. So we use a wrapper. */
static void
w32_beginthread_wrapper (void *arg)
{
the main program. On GNU/Linux, it seems like the stack is 2MB
by default, overridden by RLIMIT_STACK at program start time.
Not sure what to do with this. See also the comment in
- w32proc"new_child. */
+ w32proc.c:new_child. */
const unsigned stack_size = 0;
uintptr_t thandle;
- /* _beginthread wants a void function, while we are passed a
- function that returns a pointer. So we use a wrapper. */
thread_start_address = func;
/* We use _beginthread rather than CreateThread because the former