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);
}
}
