3

I have a such question - what is a right way to fork in PSGI/Plack application ?

On the one hand i know that PSGI app is "backend-agnostic", so it can be runned using different methods - FastCGI,CGI, etc But on the other hand i know that for example in FastCGI application we need to do some manipulation with FCGI::Request object before/after fork.

So what i must to do ?

  1. Just fork :)
  2. Do some magic manipulations and fork (What manipulations?)
  3. Rewrite application architecture => move all heavy operations into external daemon process.
Vov Pov
  • 101
  • 5

1 Answers1

1

Since PSGI is a specification, you can use it in all of those situations. If you can run a PSGI app in mod_perl, with a FastCGIs server, as CGI, or youc an run onw of the native PSGI servers like plack etc.

How you start them obviously depends on which one you choose. Mod_perl lives and dies by its apache process, CGI scripts do not to be externally started. But FastCGI and the stand-alone PSGI servers like Starman tend to be handled by the reverse proxy, or started and stopped by hand. Leaving it up to the proxy, and the PSGI server's configuration is easiest, although sometimes you'll want to be able ot control the external processes independently of the proxy.

Len Jaffe
  • 3,442
  • 1
  • 21
  • 28
  • Oh I understand that but I was asking something else Yes we can run PSGI application using various backends, using different run handlers - FCGI,CGI,Embedded PSGI servers like Starman and etc etc. But how can i fork in my app - when i don't know in what enviroment my app runned, but this _current_ enviroment may be require some special initialization for proper forking? – Vov Pov Dec 13 '13 at 13:39
  • "Forking" your app is handled by the container. For all intents, the FCGI process is your app, the Starman service is your app. They act as containers of your code, and as the interface between the proxy and your code. For instance, if you choose Apache/FastCGI, you tell apache how many fastcgi processes to fork, and which URIs to pass to the fastcgi servers. You don't manually fork your app. – Len Jaffe Dec 13 '13 at 14:06
  • You are totally right, but i asking about something else :) Perhaps is guilty my bad english ) I was asking about "manual" fork in my application. For example -> app recv some request and must perform some heavyweight operation that can be very time consuming. So i create child process using fork() call and run this operation in child process. The questions about IPC, how the user get result when is done, etc - let stay behind the scene. The main problem is this manual fork() call . – Vov Pov Dec 13 '13 at 14:27
  • Look at the IPC family of modules on CPAN, they are high level interprocess communication libraries. – Len Jaffe Dec 13 '13 at 14:41
  • You can use one to fork your process on a 'bidirectional pipe' so your processes can interact. But your overall architecture will depend on how long those 'long' requests are. Youmight be better off enqueuing the long job, and then having a separate worker to process the queue. but communicating back will also depend. Maybe the long job adds a db record that the web client can query at a later time. – Len Jaffe Dec 13 '13 at 14:45
  • Everything depends on how your application is used and how the different pieces are expected to inter-operate, and the expected timings of each. I wish I had a more precise answer, but thats the nature of complex systems. – Len Jaffe Dec 13 '13 at 14:46
  • But is fork() is allowed procedure in psgi app ? For example - fork() in psgi app runned used Plack::Handler::FCGI, so from the one point of view - my application is just a FastCGI application using FCGI module. I know that when a fork in FCGI app - i need first to call FCGI::Request->detach(), fork(), and after this in parent process FCGI::Request->attach() to prevent FCGI socket corruption in my child process. But my application is not real FCGI app, i don't have access to the FCGI object at all - he is stashed somewhere in Plack::Handler::FCGI. – Vov Pov Dec 13 '13 at 14:57
  • again, maybe fork isn't your best bet, but a job queue and workers might be a better pattern. But since we're only talking about the minutia of fork/exec rather than the domain problem you're trying to solve, I can't advise you with much confidence. – Len Jaffe Dec 13 '13 at 15:45