Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33082 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82958 invoked by uid 1010); 10 Nov 2007 16:07:40 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 82942 invoked from network); 10 Nov 2007 16:07:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Nov 2007 16:07:40 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 204.11.219.139 mail.lerdorf.com Received: from [204.11.219.139] ([204.11.219.139:35505] helo=mail.lerdorf.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 98/C2-64752-947D5374 for ; Sat, 10 Nov 2007 11:07:39 -0500 Received: from trainburn-lm-corp-yahoo-com.local (c-24-6-228-50.hsd1.ca.comcast.net [24.6.228.50]) (authenticated bits=0) by mail.lerdorf.com (8.14.2/8.14.2/Debian-1) with ESMTP id lAAG721s027659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Nov 2007 08:07:03 -0800 Message-ID: <4735D723.6050004@lerdorf.com> Date: Sat, 10 Nov 2007 08:06:59 -0800 User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Arend van Beelen CC: internals@lists.php.net, saguyer@gte.net References: <000301c82343$f3cf9df0$0201a8c0@ubar> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4745/Sat Nov 10 02:50:27 2007 on colo.lerdorf.com X-Virus-Status: Clean Subject: Re: [PHP-DEV] Making parallel database queries from PHP From: rasmus@lerdorf.com (Rasmus Lerdorf) Arend van Beelen wrote: > thanks for your thorough reply! I'm glad to see the first option appears to be preferred, as it was my first choise as well. The main reason I had some doubts was because a colleague of mine quite strongly argued (though I was still not entirely convinced) that I would find myself in an aweful lot of trouble when trying to implement a multi-threaded library inside a single-threaded PHP environment. Which is the problem I am hoping to solve by only exporting a single-threaded API. I would lean towards an event-driven approach along the lines of select() and curl_multi. You could probably copy a lot of the code from the curl_multi implementation since essentially you are doing the same thing. And yes, your colleague is correct, you will have issues doing a threaded library. Portability, threading clashes, signal handling, etc. And I don't see how scheduling is a factor here at all. On a busy web server your OS is already spreading things out over all your cores. You don't need intra-request scheduling of threads on top of that. A simple single-threaded event-driven model keeps things clean. -Rasmus