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

On Fri, Aug 8, 2008 at 6:14 AM, Joachim Ziegler <[email protected]> wrote:
>
> 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?

Yes.

Regarding missing functions in the NSPR Reference: thanks a lot
for your help.  Please continue to report problems in our
documentation.  You should also consult the comments in our
public header files.  The comments also serve as documentation.

>>> 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.

You're right.  I also thought of this security problem yesterday afternoon,
but forgot to post a message about it.  Glad you brought it up.

You need to combine this with the 'stopping' boolean flag that I
mentioned before.  The 'stopping' flag can only be set by the
master thread.  Attackers outside the server process can't set
the 'stopping' flag.

The name of the dummy resource can also be a random string
that the server generates, only known to the master thread and
worker threads within the server process.

Wan-Teh