Rasmus Lerdorf wrote:
php should defenatly in the future support multi-threading especially if
they want to prove you can do desktop apps with php and not just web
apps ;)
Which is not something we have ever stated to be a goal.
May be not, but when has that stopped people doing things ;)
E
My question is closely related to the one discussed on this php-dev
thread:
http://thread.gmane.org/gmane.comp.php.devel/32430
Someone just sent me this link, which I didn't find myself when
searching b/c the searches strip "this" from queries.
Anyway, the question is related to reference
pecl/event is available for download... ;-)
--Wez.
On 12/7/05, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> Exactly. Something based on libevent would be nice.
>
> -Andrei
>
>
> On Dec 7, 2005, at 4:49 PM, Rasmus Lerdorf wrote:
> >
> >
> > There are no plans for this. Asynchronous mechanisms are
FWIW, I can confirm that PHP using forking and "daemon" CLI classes for
async processing works like a charm. We've written a "KISS" async
mechanism that's pretty robust and works perfectly even to the tune of
several million tx's per day processed. And if you do the async handling
right it easily s
Rasmus Lerdorf wrote:
Marcus Boerger wrote:
the solution is correct. And btw just another reason to switch to svn.
Without the patch the old branches magically inherit the new file just as
we could change the past.
I have applied the patch.
Thanks Rasmus, and Marcus for your analysis.
Exactly. Something based on libevent would be nice.
-Andrei
On Dec 7, 2005, at 4:49 PM, Rasmus Lerdorf wrote:
There are no plans for this. Asynchronous mechanisms are generally
a much more efficient way to do this stuff.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
Bart de Boer wrote:
> Ilia Alshanetsky wrote:
>
>> You don't need threads, you can use fork() for that. On *nix systems it
>> is very fast, nearly as fast as threads and much safer to boot. And you
>> can already do forking in PHP via PCNTL extension's pcntl_fork()
>> function.
>>
>> Ilia
>
>
>
Joseph Crawford wrote:
php should defenatly in the future support multi-threading especially if
they want to prove you can do desktop apps with php and not just web apps ;)
Which is not something we have ever stated to be a goal.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
php should defenatly in the future support multi-threading especially if
they want to prove you can do desktop apps with php and not just web apps ;)
--
Joseph Crawford Jr.
Zend Certified Engineer
Codebowl Solutions, Inc.
1-802-671-2021
[EMAIL PROTECTED]
Well I posted there first, and someone helped me believe that & on
objects does indeed legitimately not bump the refcount, but no one
knows about $this->this. And there's another similar thread on the
dev list anyway which was answered usefully: http://
aspn.activestate.com/ASPN/Mail/Message
are you using ph4 or php5?
PHP5
are you setting $this->this yourself or 'is it just there'?
No, I'm not setting it, just reading it (see addChildObject() code
below), if that's what you mean.
-Alan
Alan Pinstein wrote:
Hi all-
I've been trying to avoid circular references in some dat
Try proc_open().
--Wez.
On 12/7/05, Bart de Boer <[EMAIL PROTECTED]> wrote:
> Ilia Alshanetsky wrote:
> > You don't need threads, you can use fork() for that. On *nix systems it
> > is very fast, nearly as fast as threads and much safer to boot. And you
> > can already do forking in PHP via PCNTL
Antony Dovgal wrote:
On 07.12.2005 18:40, Alan Pinstein wrote:
Hi all-
Please use php-general@lists.php.net for questions regarding development
*in* PHP.
Please stop bashing other people's messages for the sole reason they do
not deal with C code. The question was perfectly relevant.
Sara Golemon wrote:
I've got two...well...threads... going on this concept One is a very
non-true-threading apprach which involves a combination of ticks and
Runkit_Sandbox which I hope to get around to sooner rather than later.
The other is a longer-range plan designed to work specifically
Ilia Alshanetsky wrote:
You don't need threads, you can use fork() for that. On *nix systems it
is very fast, nearly as fast as threads and much safer to boot. And you
can already do forking in PHP via PCNTL extension's pcntl_fork() function.
Ilia
That sounds sufficient enough. Although I gues
Rasmus Lerdorf wrote:
Bart de Boer wrote:
Are there any future (or current) plans for multithreading in PHP?
There are no plans for this. Asynchronous mechanisms are generally a
much more efficient way to do this stuff.
-Rasmus
With asynchronous I'm asuming you mean mechanisms where you
> I was wondering. (And I'm probably the 1000th person asking this.) With
> all the multiple-core processors and servers popping up lately, are
> there any future (or current) plans for multithreading in PHP?
>
I've got two...well...threads... going on this concept One is a very
non-true-thread
You don't need threads, you can use fork() for that. On *nix systems it
is very fast, nearly as fast as threads and much safer to boot. And you
can already do forking in PHP via PCNTL extension's pcntl_fork() function.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Bart de Boer wrote:
Dear PHP creators,
I was wondering. (And I'm probably the 1000th person asking this.) With
all the multiple-core processors and servers popping up lately, are
there any future (or current) plans for multithreading in PHP?
It's not unlikely to have a PHP script that, for e
Dear PHP creators,
I was wondering. (And I'm probably the 1000th person asking this.) With
all the multiple-core processors and servers popping up lately, are
there any future (or current) plans for multithreading in PHP?
It's not unlikely to have a PHP script that, for example, needs to send
I'd like to resurrect php-i18n list and shift all Unicode/i18n
discussions over there so that people interested in these topics can
better focus on them. To that end I have subscribed a few of you (haha)
to it already so don't be surprised.
- Andrei
--
PHP Internals - PHP Runtime Development
Hi Dmitry,
What about adding "if (request) " at the beginning of the
"flush_result = FCGX_FFlush(request->out);" string? You see, you have
to do that call, because else you are not flushing at all in fastcgi
mode at all!-)
Thanks, Ilya.
12/7/2005, "Dmitry Stogov" <[EMAIL PROTECTED]> вы писали:
Hi Ilya,
Your patch is wring.
It may try access request->out then request is NULL.
Thanks. Dmitry.
> -Original Message-
> From: Ilya M. Slepnev [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 07, 2005 1:08 AM
> To: internals@lists.php.net
> Cc: [EMAIL PROTECTED]
> Subject: [PHP-DE
I don't think PHP-general would be of much help here. After all, his
question was whether this behavior is intentional or not, and if it
can be relied upon in the future. To me, it's an engine thing. And
I'm interested in what the devs can say about this, too.
- David
Am 07.12.2005 um 17
On 07.12.2005 18:40, Alan Pinstein wrote:
Hi all-
Please use php-general@lists.php.net for questions regarding development *in* PHP.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 07.12.2005 01:08, Ilya M. Slepnev wrote:
Hi,
Now, flush() works in fastcgi...
It seems, that the developers forgot about lazy compilation!-)
What the heck is that?
What do you think about that?
I think you need to explain what are you trying to fix and why.
--
Wbr,
Antony Dovgal
--
are you using ph4 or php5?
are you setting $this->this yourself or 'is it just there'?
Alan Pinstein wrote:
Hi all-
I've been trying to avoid circular references in some data import
scripts and finally figured out how to do it. However, I wanted to ask
you guys to make sure that what I'm do
Hi,
Now, flush() works in fastcgi...
It seems, that the developers forgot about lazy compilation!-)
What do you think about that?
Best rgds, Ilya
? khext.patch
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php-src/sapi/cgi/cgi
Hi,
Now, flush() works in fastcgi...
It seems, that the developers forgot about lazy compilation!-)
What do you think about that?
Best rgds, Ilya
? khext.patch
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php-src/sapi/cgi/cgi
Hi all-
I've been trying to avoid circular references in some data import
scripts and finally figured out how to do it. However, I wanted to
ask you guys to make sure that what I'm doing is something that's
legit and can be relied on into the future.
Also, please note that I tried searchi
hi,
i had a slight problem with
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE
[42P05]: Duplicate prepared statement: 7 ERROR: prepared statement
"pdo_pgsql_stmt_086eebf4" already exists' in /home/thies/public_html/
portal-HEAD/include/pw.db/table.php:670
some inves
Marcus Boerger wrote:
the solution is correct. And btw just another reason to switch to svn.
Without the patch the old branches magically inherit the new file just as
we could change the past.
I have applied the patch. SVN has its own set of problems.
-Rasmus
--
PHP Internals - PHP Runtim
Jani Taskinen wrote:
Not that we will patch the repository files, but why do you care?
You actually use some old release branch? :)
In case I wasn't clear, or the patch wasn't clear, this is -every- historical
checkout that's broken. Including those in the past month.
>If you're
Hello Jani,
the solution is correct. And btw just another reason to switch to svn.
Without the patch the old branches magically inherit the new file just as
we could change the past.
best regards
marcus
Wednesday, December 7, 2005, 11:13:10 AM, you wrote:
> On Wed, 7 Dec 2005, Edin Kadribasi
On Wed, 7 Dec 2005, Edin Kadribasic wrote:
Jani Taskinen wrote:
Not that we will patch the repository files, but why do you care?
You actually use some old release branch? :)
I think that we should try to preserve the possiblity to checkout an old
version of PHP directly from the CV
Jani Taskinen wrote:
>
> Not that we will patch the repository files, but why do you care?
> You actually use some old release branch? :)
I think that we should try to preserve the possiblity to checkout an old
version of PHP directly from the CVS.
Edin
--
PHP Internals - PHP Runtime D
Not that we will patch the repository files, but why do you care?
You actually use some old release branch? :)
--Jani
On Wed, 7 Dec 2005, William A. Rowe, Jr. wrote:
Two weeks ago;
ext/pcre/config0.m4
was added by duplicating ext/pcre/config.m4,v directly in the CVS repository.
Two weeks ago;
ext/pcre/config0.m4
was added by duplicating ext/pcre/config.m4,v directly in the CVS repository.
Unfortunately this breaks every historical checkout, due to the now duplicate
existance of config0.m4 and config.m4, causing duplicate builds of the pcre
extention.
Of course, if
38 matches
Mail list logo
