Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47701
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.153 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=date:from:reply-to:x-priority:message-id:to:subject:mime-version
         :content-type:content-transfer-encoding;
        b=YT/+fYwZ4ffyOzWUuO75I4mTIUmc0ZSy9aFOWcl60H/g3lsMGqvN+dnGLCCZ6LxBH8
         5umyVbjIyeG0EuKSeyOlwiym9Dbn0gzFFXAyNtXWPn8YdO9v/0Wyg7rznNmK/6Wz5Pcq
         9/W4L6p3lWhWFzhmE792kfN2ZpGBN7H0rijno=
Date: Thu, 1 Apr 2010 16:32:15 +0200
Reply-To: speedy <speedy.spam@gmail.com>
Message-ID: <1941231697.20100401163215@gmail.com>
To: internals@lists.php.net
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Subject: php and multithreading (additional arguments)
From: speedy.spam@gmail.com (speedy)

Hello PHP folks,

      I've seen this discussed previously, and would like to add a few
      arguments for the multi-threading side vs. async processing,
      which I've seen mentioned as a viable alternative:

      1. Imagine that from time to time, some background processing takes 1
      second of CPU time - w/o multithreading, all your async operations,
      like accepting a connection to a socket, aio or others are basically
      stalled. So, async is a good approach, but does not work as a magic
      wand for all problem spaces. Alternatively, you could fork and then d=
o the
      processing, but then the state syncing of the forked background proce=
ssing
      results with the main thread requires a whole new protocol / switchin=
g to
      interprocess communication, which makes such developments unnecessari=
ly
      hard. Threads exist for a _reason_ not only because they sound cool.

      2. Without thread support, it is not possible to use multi-core proce=
ssing
      paradigms directly from PHP - which means PHP relies on external fram=
eworks for
      that feature, which, in a sense, makes it a non-general-purpose langu=
age.
      It _could become_ a general purpouse tool, if it had proper multi-thr=
eading
      support built-in.

      I, personally, considered developing websockets / nanoserv server sta=
ck with PHP
      and bumped into the multithreading limitation - AFAIK it is the only =
big feature
      separating PHP from the general purpouse languages. Everything else i=
s well
      integrated with lots of external libraries/modules giving rise to pot=
ential rapid
      application development while using it.

      Cheers and let me know about your thoughts, and potential core implem=
entation
      issues regarding developing this language feature.

--=20
Best regards,
 speedy                          mailto:speedy.spam@gmail.com