Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

[FCGI.pm] - not threads-safe?

by zdm (Sexton)
on Aug 18, 2013 at 15:40 UTC ( #1049917=perlquestion: print w/ replies, xml ) Need Help??
zdm has asked for the wisdom of the Perl Monks concerning the following question:

Hello. Following code produce segmentation fault:
#!/usr/bin/env perl use v5.16.3; use threads (exit => 'threads_only'); use threads::shared; use FCGI; threads->create(\&thread); threads->create(\&thread); threads->create(\&thread); while (threads->list(threads::all)) { sleep 1 } #wait until has thr +eads sub thread { sleep 3; threads->detach; threads->exit; return; } 1; __END__
but if i require FCGI first time in thread, such as:
#!/usr/bin/env perl use v5.16.3; use threads (exit => 'threads_only'); use threads::shared; threads->create(\&thread); threads->create(\&thread); threads->create(\&thread); while (threads->list(threads::all)) { sleep 1 } #wait until has thr +eads sub thread { require FCGI; # <--- HERE IS THE DIFFERENCE sleep 3; threads->detach; threads->exit; return; } 1; __END__
thread can exit without any errors.

This bug prevent use FCGI.pm with threads. Does somebody has a working solution to use FCGI in main thread?

Comment on [FCGI.pm] - not threads-safe?
Select or Download Code
Re: [FCGI.pm] - not threads-safe?
by sundialsvc4 (Monsignor) on Aug 19, 2013 at 18:54 UTC

    Ping?!   (Interested party.)

    It certainly seems that you have found a significant issue, and a workaround to it.   Will anyone more knowledgeable than I, please comment as to the performance (etc ...) implications of this ... of what this code vs. that code causes the Perl interpreter to do?   Maybe of why this is happening in the first place?

Re: [FCGI.pm] - not threads-safe?
by BrowserUk (Pope) on Aug 19, 2013 at 19:03 UTC
    This bug prevent use FCGI.pm with threads. Does somebody has a working solution to use FCGI in main thread?

    It isn't a bug. It means that FCGI is not thread-safe.

    And given what FCGI does:

    Instead of creating a new process for each request, FastCGI uses persistent processes to handle a series of requests. These processes are owned by the FastCGI server, not the web server. 1

    To service an incoming request, the web server sends environment information and the page request itself to a FastCGI process over a socket (in the case of local FastCGI processes on the web server) or TCP connection (for remote FastCGI processes in a server farm). Responses are returned from the process to the web server over the same connection, and the web server subsequently delivers that response to the end-user. The connection may be closed at the end of a response, but both the web server and the FastCGI service processes persist.2

    Each individual FastCGI process can handle many requests over its lifetime, thereby avoiding the overhead of per-request process creation and termination. Processing of multiple requests simultaneously can be achieved in several ways: by using a single connection with internal multiplexing (i.e. multiple requests over a single connection); by using multiple connections; or by a combination of these techniques. Multiple FastCGI servers can be configured, increasing stability and scalability.

    it almost certainly could never be thread-safe.

    If you describe why you think you need threads, maybe we can help.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      I need FCGI.pm in threads because this is a single way to create preforking fcgi server, which can process parallel requests under window.

      FCGI.pm just listen socket, accept connection and populate the environment hash.

      Why it could never be threads safe? It's perfectly work in threads under MSWin and Linux, except segfault when thread has been destroyed.

        It's perfectly work in threads ... except segfault when thread

        Tada!


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: [FCGI.pm] - not threads-safe?
by Anonymous Monk on Aug 20, 2013 at 21:18 UTC
      This:
      use Thread;

      is a dead duck since 5.8.0.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        use Thread; is a dead duck since 5.8.0.

        Yes, but https://metacpan.org/module/Thread Ricardo SIGNES / perl-5.18.1 / Thread says its been reworked using threads:: for old code

        The working pattern for the OP is following the same pattern., and the code uses perl_mutex

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1049917]
Approved by Perlbotics
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2014-07-31 04:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (244 votes), past polls