Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82210 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14324 invoked from network); 9 Feb 2015 02:16:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Feb 2015 02:16:58 -0000 Authentication-Results: pb1.pair.com header.from=ua.san.alex@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ua.san.alex@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.173 as permitted sender) X-PHP-List-Original-Sender: ua.san.alex@gmail.com X-Host-Fingerprint: 209.85.213.173 mail-ig0-f173.google.com Received: from [209.85.213.173] ([209.85.213.173:51049] helo=mail-ig0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 15/51-26926-89818D45 for ; Sun, 08 Feb 2015 21:16:57 -0500 Received: by mail-ig0-f173.google.com with SMTP id a13so13637738igq.0 for ; Sun, 08 Feb 2015 18:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/POVGNfKh0TKlFS5fuS85Bu4O9Y4Yt6DJ/u3onDeMso=; b=ckskT62IgE7LPzjRuDNisGkxtq32SWBUDTaGHOgFkkrai2qtEQV8U9ywSoSkoGjDVl MOz+uYGp1vzC1u18FK6jzGBTWA7Fgtj9XwjBvMPi3BzYqPE+5Ul/9wmxyxm1eo4pAAwj 5d23AEF2v8Kpw7rZIBvYoMnfC2NIBD06Xtb/Nfd7I4AzHkJgxFltFQqGgpXbAnLF3Ji1 cRJOaxVeyLd/qjsW5IBOiv0GzIIT2Avdg9p8bQLfV4LlvJMRJMO5gHeSrNp1q1dM23he vG+JGqVvSwqzfjjdduGVRAAgH11ng/1hAXNiWuvzEZ0jjp5wVPBAtmT7pHiDW2K8E8OD PS/Q== MIME-Version: 1.0 X-Received: by 10.50.142.106 with SMTP id rv10mr14669964igb.18.1423448213567; Sun, 08 Feb 2015 18:16:53 -0800 (PST) Received: by 10.50.93.3 with HTTP; Sun, 8 Feb 2015 18:16:53 -0800 (PST) In-Reply-To: <54D7FEBA.1070304@gmail.com> References: <54D7F5D5.4050808@gmail.com> <54D7FEBA.1070304@gmail.com> Date: Mon, 9 Feb 2015 04:16:53 +0200 Message-ID: To: Rowan Collins Cc: internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP From: ua.san.alex@gmail.com ("S.A.N") 2015-02-09 2:26 GMT+02:00 Rowan Collins : > On 09/02/2015 00:02, S.A.N wrote: >> >> 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] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > 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: 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 ]; }