Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^5: [FCGI.pm] - not threads-safe?

by BrowserUk (Pope)
on Aug 20, 2013 at 14:30 UTC ( #1050189=note: print w/ replies, xml ) Need Help??


in reply to Re^4: [FCGI.pm] - not threads-safe?
in thread [FCGI.pm] - not threads-safe?

It mean, that FCGI.pm MUST have properly implemented cleanup routine,

Why "MUST" it? Because you said so? It DOESN'T, and there is a good reason:

It makes no sense to use threads with FCGI

I'm not going to explain that. YOU need to go out and read up on FastCGI and FCGI to understand why that is so.


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.


Comment on Re^5: [FCGI.pm] - not threads-safe?
Re^6: [FCGI.pm] - not threads-safe?
by zdm (Sexton) on Aug 20, 2013 at 14:52 UTC

    Hm, i work with FastCGI protocol and applications more than five years, and, really, don't understand, why there is no sense to use FastCGI with threads? Maybe i miss something important?

    What is the difference between threads and forked processes in this context and why use FastCGI with forks has sense but with threads - no?

    Please, explain in few words.
      why there is no sense to use FastCGI with threads?

      Because FastCGI and FCGI have been developed to expect the forking model -- ie. separate processes with no shared state. They therefore have never been designed to be thread-safe.

      That's not to say that a FastCGI-style of operation -- persistent perl instances servicing many serial connections -- wouldn't be possible; and perhaps even effective; but it would need to be written from the ground up to understand the environment it is operating in and be thread-safe from the get-go.

      It would be a different animal with different requirements and you will not get anywhere trying to slap threads on top of FCGI.

      If you need more concurrency, start more FastCGI handler processes. That's the way it is designed to work.

      What is the difference between threads and forked processes in this context

      Sorry to put it this way, but if you do not understand that difference; you should not be using threads.

      Please, explain in few words.

      Not possible; which I why I suggested you go do some reading.


      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.

        FastCGI server - is just a tcp server with own communication protocol, like many others. It does not matter how it was designed more than 20 years ago, when perl has no ithreads and apache can run only cgi scripts.

        Problem not in incorrect FastCGI usage and misunderstanding FastCGI specification, but in FCGI.pm implementation, that does not meet the modern requirements.

        In context of this task there is no difference between threads and processes. I don't use shared variables, etc...

        Please, suggest solution to shutdown thread correctly, if you know how.

        Thanks.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1050189]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (11)
As of 2014-10-01 16:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (29 votes), past polls