uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP

2015-02-09 2:26 GMT+02:00 Rowan Collins rowan.collins@gmail.com:

You're right, but there is no threading issues.
One worker synchronously execute requests, but may run parallel many
workers.

I'm not sure what you mean by this. I can see 3 ways of handling incoming
web requests, as it affects PHP's threading:

A) The current "shared nothing" model: the web server may have multiple
processes or threads, but each requested is executed in a completely
separate global scope of PHP.
B) Each process or thread in the web server spawns an instance of the
application; the application has a global state within that instance, and
startup and shutdown code; the instance is sent multiple requests, but has
no way to know if it is getting all the requests, half the requests, or one
hundredth of the requests.
C) The web server executes the application once, which sets up its global
state, and then spawns an internal threading model; each request is sent to
a worker thread within PHP, which has to synchronise with other threads in
order to access any aspect of global state.

I guess you are suggesting option (B), which is what I was referring to when
I said that global state would be "arbitrarily shared" - if handling a
particular request caused any global state to be changed, such as
registering an error handler, it could affect anything from 0 to 100% of
subsequent requests, depending on how the web server is configured.

The code therefore needs to avoid relying on any such global state at all,
which basically restricts you to a subset of the current language. For it to
become the default way of running PHP, huge changes would be needed to adapt
code to this new model.

The reason I mentioned threading is that under option (C), migration becomes
a bit easier in some ways: you can move some things which are currently
global state into an explicitly per-thread state, allowing old behaviour to
be emulated; and you can leave other things in synchronized global state,
like ini settings, solving the problem of "50% of my threads have a
different error handler registered".

Regards,

--
Rowan Collins
[IMSoP]

--

Yes, option (B) is more like.

Let me show in your PHP code, how the option that I like, we have the
actual application work that way in the pecl-event module, we are
satisfied, it is convenient and very fast for PHP.

This is a very rough and simplified code:
<?php

class App
{
public static $db; // Persistent open connection to database
public static $redis; // Persistent open connection to Redis
public static $cache; // Persistent cache application

public $request;
public $response;
public $session;

public function __construct(HTTP $object)
{
    $this->request  = $object->request;
    $this->response = $object->response;
}

public function open()
{
    /*
       Routing by $this->request, may be auth and open

$this->session (analog $_SESSION), or throw Exception.
*/

    return $this;
}

public function run()
{
    /*
       Run your business logic...
    */

    return $this;
}

public function close()
{
    /*
       Run finally logic, and cleaning output buffer
    */

    $this->response->body = `ob_get_clean()`;

    return $this;
}

public static function init()
{
    /*
       Application configuration as static class state
    */

    `ob_start()`;
    set_error_handler(/*...*/);

    self::$db    = new DBConnection;
    self::$redis = new Redis;
    self::$cache = new Cache;
}

}

// Bootstrap, run configuration
App::init();

// Handler WSGI (not multi-thread)
function application(HTTP $object)
{
$app = new App($object);

$app->open()->run()->close();

return
[
    $app->response->code,
    $app->response->headers,
    $app->response->body
];

}