in reply to eval with timeout, threaded perl

Are your "very good reasons" good enough to justify using a threading implementation which is experimental and is known not to be thread-safe?

You haven't said what you are doing, but my strong recommendation is to use an existing solution, such as Apache with mod_perl.

As for your problem, the best way I can think of to solve it with threading is to split the child thread into 2. One to write back to the client, one to wait a fixed time, and if the page is still loading send a timeout message and then close the connection. (The backend work still gets done either way.) Hope and pray that you don't have a race between when the sleeper starts writing its timeout message and when the other thread chooses to finish what it is doing...

  • Comment on Re (tilly) 1: eval with timeout, threaded perl

Replies are listed 'Best First'.
Re: Re (tilly) 1: eval with timeout, threaded perl
by erroneousBollock (Curate) on Jan 14, 2002 at 19:02 UTC
    Are your "very good reasons" good enough to justify using a threading implementation which is experimental and is known not to be thread-safe?
    Of course ;p I am aware of the threading stability issues, including those affecting non-threaded functionality in the threaded perl interpreter. (Eventually, probably long before perl6 :) that'll become less of an issue.)

    Hmmmm, as to your suggestion.... not robust but a good idea. I wonder if i can pass 2 tie()'d filehandles to the client code (replacing STDIN & STDOUT), with explicit functionality to stop the close() from working, replacing it with some cond_wait() on a per-thread scalar.... hmmmm, an async() block cotaining a timer either will or wont have locked that scalar.

    Ewwww, it sounds just evil enough to work!
    Thanks I'll try :)
[reply]

In Section Seekers of Perl Wisdom