Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75022 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47814 invoked from network); 20 Jun 2014 16:29:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jun 2014 16:29:27 -0000 Authentication-Results: pb1.pair.com smtp.mail=rdlowrey@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rdlowrey@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.182 as permitted sender) X-PHP-List-Original-Sender: rdlowrey@gmail.com X-Host-Fingerprint: 209.85.214.182 mail-ob0-f182.google.com Received: from [209.85.214.182] ([209.85.214.182:42258] helo=mail-ob0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1C/F0-40391-66164A35 for ; Fri, 20 Jun 2014 12:29:26 -0400 Received: by mail-ob0-f182.google.com with SMTP id nu7so1326138obb.13 for ; Fri, 20 Jun 2014 09:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aZ9oslJ1PRnDe+im8wwQx9EYRk8fagAp73cMd8/9yvs=; b=Q0cg5GdRFMIg402DaJG4Z7eRg/cyy3dxj9NK4Qm6v0HmLRsEIAQo0D5QWw1084zIRE 3XzUPx9dnXEvxaFO5sN/z+iFU6k6RuSfBqVVqGOg53o1S2D/kL58ZyZe8JTo/cW3tubz ZpYXVVb6HCCHbgqaPUpUKaJhTTeFWNLX/AW7EANysufgp29XNej2XE+ARAN94hyQ+5pV +XY1167zptJukzbexBh5cwKHqoCZuihhDZRTD7pbKw+qAjiey9G+bxphzA9tss4okyQs xn0oQJ6Lv9DDur64A/nzgqYQM1IW/Pap4wSltuIYQ9BV8pF6WB/Se3uKDGtcxnEeCcWz VSfw== MIME-Version: 1.0 X-Received: by 10.182.24.38 with SMTP id r6mr4605926obf.10.1403281763298; Fri, 20 Jun 2014 09:29:23 -0700 (PDT) Received: by 10.202.199.20 with HTTP; Fri, 20 Jun 2014 09:29:23 -0700 (PDT) Date: Fri, 20 Jun 2014 12:29:23 -0400 Message-ID: To: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a11c29c8205753004fc46ff30 Subject: Re: Refactoring our IO multiplexing layer From: rdlowrey@gmail.com (Daniel Lowrey) --001a11c29c8205753004fc46ff30 Content-Type: text/plain; charset=UTF-8 On 17 June 2014 12:05, Julien Pauli wrote: > Second question will be : do we use, and then link against libevent > (or any other lib that could fit the need) Another particularly strong argument for using a libuv backend is that it packages fully non-blocking and cross-OS filesystem IO capabilities. You simply cannot perform non-blocking filesystem IO without delegating the work to threads and subsequently notifying the main thread asynchronously upon completion. Here's a useful intro on this topic: http://www.remlab.net/op/nonblock.shtml In theory libuv would completely obviate the need for most (all?) of PHP's existing filesystem code. If we're talking nbio backend alternatives, libuv vs. libevent shouldn't really be a question. P.S. As Generators are now a thing in PHP (thanks, Nikita!), the addition of built-in non-blocking facilities would mean the language has all the necessary building blocks to utilize powerful language level concurrency structures. To avoid userland segmentation and massive library duplication I think a separate RFC to consider basic structures like CommonJS Promises or Scala-style Future primitives (my personal preference) would also be expedient. --001a11c29c8205753004fc46ff30--