Re: Problem interrupting threads in PR_Accept() wiht PR_Interrupt()

Wan-Teh Chang wrote:
>> Is there any solution to this problem? Can I make PR_Send() and
>> PR_TransmitFile() ignore the PR_Interrupt()?
>>
>> You can use PR_BlockInterrupt and PR_UnblockInterrupt to
>> block and unblock PR_Interrupt.  I just checked our implementation.

The functions PR_BlockInterrupt and PR_UnblockInterrupt are not mentioned on

http://www.mozilla.org/projects/nspr/reference/html/prthrd.html

(I'm really willing to contribute; until now, I can only describe what I
do not understand or find missing.)


>> We're not checking the "interrupt blocked" flag in some places,
>> for example,
>> http://mxr.mozilla.org/nspr/source/nsprpub/pr/src/pthreads/ptio.c#601
>>
>> 599                 rv = poll(&tmp_pfd, 1, msecs);
>> 600
>> 601                 if (self->state & PT_THREAD_ABORTED)  <=== BUG
>> 602                 {
>> 603                     self->state &= ~PT_THREAD_ABORTED;
>> 604                     op->result.code = -1;
>> 605                     op->syserrno = EINTR;
>> 606                     op->status = pt_continuation_done;
>> 607                     return;
>> 608                 }
>>
>> We should be using if (_PT_THREAD_INTERRUPTED(self))
>> on line 601.  If you want to use this approach, we'll need to fix
>> this bug.  You can search for all such tests in ptio.c and change
>> them to use the _PT_THREAD_INTERRUPTED macro.

So the approach would to call PR_BlockInterrupt() for the worker thread
right after the PR_Accept(), disabling interruption, and enabling it
again by PR_UnblockInterrupt() just before going into PR_Accept() at the
end of the main loop?

>> You can also use a solution that Julien or Nelson suggested before:
>> your master thread can connect to the worker threads and issue
>> a special shutdown command to shut them down cleanly.  This
>> solution doesn't use PR_Interrupt.  But your application protocol
>> must allow this special shutdown command.  For example, suppose
>> the server is an HTTP server.  You can define a dummy
>> resource name "GET /shutdown HTTP/1.1" as the special shutdown
>> command.

This sounds nice and clean, but isn_'t this a potential security risk?
Then everybody can send the shutdown signal as a normal request to the
worker thread. Hmm, I could look from which machine this special request
comes, or use a password!? I'll have to discuss this approach with my
project leader.

Joachim