🚀 go-pugleaf

In article <1992Aug04.192148.28303@hpmcaa.mcm.hp.com> ford@hpmcaa (Dan Ford) writes:

>  I have noticed that there are many OS/2 2.0 control program functions that
>return (among other possible values) the value ERROR_INTERRUPT.  For example
>the function DosRequestMutexSem can return this value.  The documentation is
>very skimpy about what conditions can cause this.  It simply says something
>like "this value will be returned if the thread was interrupted while 
>waiting for the semaphore".  
>
>  Does anyone have more information on this?  How can a thread be interrupted?

I can't be sure that there aren't other reasons under 2.0, but under 1.3,
a prime reason for this to happen was that your code received a signal, and
thread 1 of your application was blocked in a semaphore call.  Since all
signals are handled by thread 1, it would interrupt the semaphore block, and
let the code process the signal (presuming you were trapping it), and the
semaphore call would return with ERROR_INTERRUPT.  Generally, code would look
for this return, and then just restart the semaphore call.

I presume this is done because during the processing of the signal, you are
no longer appropriately blocked within the kernel for the resource protected
by the semaphore, so the function can't just be continued upon return from
the signal handler.

Oh, and this return also came up when I was writing an IFS toolkit - if I
was blocked on a semaphore during a file system operation, and the user hit
Ctrl-C in the application that triggered the file system request, my
semaphore operation would return with ERROR_INTERRUPT.

>I suspect that this is a return code used during the debugging of OS/2 itself.
>I understand that at very low levels (inside the operating system) the thread
>must supply a unique identifier when it is blocking itself, and that if that
>identifier is not unique, another thread could be inadvertently unblocked when
>it is time for this thread to be unblocked.  Could this be a relic of this?

I'm not sure, but it sounds doubtful.  I think it simply means that you were
interrupted by some outside event (signals, user break, etc..) and that the
system had to free up your thread by interrupting the blocked call.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/