msg_t * OS2_receive_message (qid_t qid, int blockp, int interruptp) { tqueue_t * tqueue = (QID_TQUEUE (qid)); msg_t * message; if (tqueue == 0) { if ((OS2_current_tid ()) != OS2_scheme_tid) /* This behavior is a little random, but it's based on the idea that if an inferior thread is reading from a closed channel, this is due to a race condition, and the fact that the channel is closed means that the thread is no longer needed. So far this has only happened under one circumstance, and in that case, this is the correct action. */ OS2_endthread (); else OS2_error_anonymous (); } while (1) { while ((read_tqueue (tqueue, 0)) != 0) ; if ((TQUEUE_TYPE (tqueue)) == tqt_scm) { process_interrupt_messages (); if (interruptp) deliver_pending_interrupts (); } message = (read_subqueue (qid)); if ((!blockp) || (message != 0)) break; (void) read_tqueue (tqueue, 1); } return (message); }
void OS2_request_mutex_semaphore (HMTX s) { while (1) { APIRET rc = (dos_request_mutex_sem (s, SEM_INDEFINITE_WAIT)); if (rc == NO_ERROR) break; /* This return code has been regularly occurring on my machine. On one occurrence, I proceeded past the error in the debugger, and the program continued working without errors. However, more recently proceeding past this error has caused a subsequent error when unlocking the semaphore because the lock didn't succeed. IBM tech support is mystified because this code appears nowhere in their sources. */ if (rc == 3000) { PID pid; TID tid; ULONG count; DosQueryMutexSem (s, (&pid), (&tid), (&count)); if ((count > 0) && (tid == (OS2_current_tid ()))) break; } else if (rc != ERROR_INTERRUPT) OS2_error_system_call (rc, syscall_dos_request_mutex_sem); } }