Ok, had a play with this
updated copy on
http://docs.akbkhome.com/threads.tgz
added a few of pthreads calls to TSRM.c
did most of the testing without this abstraction layer - just to see if
I could get it to work.
used php_exectute_script, rather than getting clever and copying the
At 04:29 PM 8/3/2002 +0800, Alan Knowles wrote:
Ok, had a play with this
updated copy on
http://docs.akbkhome.com/threads.tgz
added a few of pthreads calls to TSRM.c
did most of the testing without this abstraction layer - just to see if I
could get it to work.
used php_exectute_script,
By the way, if we do end up making this kind of thing mainstream we should
probably use APR (or another library) for thread abstraction. I wouldn't
want to do all of that work over.
Andi
At 04:29 PM 8/3/2002 +0800, Alan Knowles wrote:
Ok, had a play with this
updated copy on
At 05:43 PM 8/1/2002 +0800, Alan Knowles wrote:
It's not about looking at the perl code, that will tell you nothing
unless you know perl internals. It's about the way the interpreter
works, some of the architecture, that is simular to PHP. In PHP, threads
are isolated, kind of like seperate
Alan Knowles wrote:
Ok, had a play with this
updated copy on
http://docs.akbkhome.com/threads.tgz
added a few of pthreads calls to TSRM.c
did most of the testing without this abstraction layer - just to see if
I could get it to work.
used php_exectute_script, rather than getting
Andi Gutmans wrote:
By the way, if we do end up making this kind of thing mainstream we
should probably use APR (or another library) for thread abstraction. I
wouldn't want to do all of that work over.
Andi
That would be nice, but not sure how realistic at this point. Idealy,
we
I've cleaned things up a bit, removed code from tsrm and added it to a
new file, and commited to pecl. This way those interested can start
playing with and developing the module.
Shane
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
At 12:40 PM 8/3/2002 -0700, Shane Caraveo wrote:
Andi Gutmans wrote:
By the way, if we do end up making this kind of thing mainstream we
should probably use APR (or another library) for thread abstraction. I
wouldn't want to do all of that work over.
Andi
That would be nice, but not sure how
This isn't always ideal. I would rather see the threads as a function not a
separate file. Forcing threads to a file would be pretty limited.
-brad
--- Andi Gutmans [EMAIL PROTECTED] wrote:
I still think that if you're going to implement such a thread extension it
shouldn't try and copy it's
At 09:20 PM 8/3/2002 -0700, Brad LaFountain wrote:
This isn't always ideal. I would rather see the threads as a function not a
separate file. Forcing threads to a file would be pretty limited.
I don't think it's that limited. I also don't think that duping the whole
thread's address space is a
Andi Gutmans wrote:
At 12:40 PM 8/3/2002 -0700, Shane Caraveo wrote:
Andi Gutmans wrote:
By the way, if we do end up making this kind of thing mainstream we
should probably use APR (or another library) for thread abstraction.
I wouldn't want to do all of that work over.
Andi
That
Andi Gutmans wrote:
I still think that if you're going to implement such a thread extension
it shouldn't try and copy it's parents data-structures. It'd be very
slow and prone to errors.
Andi,
Currently only the thread_include function that Alan wrote works. I
have idea's for doing the
Ok, had a slight play with it again..
I did eventually find the perl code for threading although without an
lxr server it's pretty much impossible to decipher all the macros they
use..
The reality is I'm waving in the dark a bit - I've got a bit of spare
time to play with it, but not really
Alan Knowles wrote:
Ok, had a slight play with it again..
I did eventually find the perl code for threading although without an
lxr server it's pretty much impossible to decipher all the macros they
use..
It's not about looking at the perl code, that will tell you nothing
unless you
It's not about looking at the perl code, that will tell you nothing
unless you know perl internals. It's about the way the interpreter
works, some of the architecture, that is simular to PHP. In PHP,
threads are isolated, kind of like seperate processes, but in threads.
From my
On 31 Jul 2002, Jason T. Greene wrote:
Instead of mutexing the entire interpreter to death, why don't you try
creating multiple interpreters (each in a thread), and then come up with
a sharing mechanism.
Sounds like duplication some other thing :)
Derick
On Wed, 2002-07-31 at 03:57, Alan
On Thu, 2002-08-01 at 08:04, [EMAIL PROTECTED] wrote:
On 31 Jul 2002, Jason T. Greene wrote:
Instead of mutexing the entire interpreter to death, why don't you try
creating multiple interpreters (each in a thread), and then come up with
a sharing mechanism.
Sounds like duplication
On Thu, 2002-08-01 at 04:43, Alan Knowles wrote:
It's not about looking at the perl code, that will tell you nothing
unless you know perl internals. It's about the way the interpreter
works, some of the architecture, that is simular to PHP. In PHP,
threads are isolated, kind of
Hi Alan,
I've missed the start of this thread on threads because our
internet connection was physically down for a couple of days,
but hopefully what I've said here is useful to you.
It started as a couple of comments but then grew a bit long...
You might find some of the code in the
To make threading useful, you would need to somehow arrange for multiple
threads to access the same underlying zval data without blocking all
the threads. This just isn't possible AFAIK.
Yes, this is definitely not possible without greatly modifying the
engine's zval management (which would
Im looking at adding threading to php, (for the cgi/cli stuff)..
The story so far:
I've created an extension which diverts all zend_execute calls into the
extension - phpthreads_execute.
this function is a copy of zend_execute with a few modifications
- to copy restore things
This is interesting Shane and I started talking about php threads at OSCON.
But baiscally your soulition won't work. I can't remember the specfic reason. I
think i tried the same thing along time ago. If it were that simple it probally
would have been done already :).
For threading php you will
Instead of mutexing the entire interpreter to death, why don't you try
creating multiple interpreters (each in a thread), and then come up with
a sharing mechanism.
-Jason
On Wed, 2002-07-31 at 03:57, Alan Knowles wrote:
Im looking at adding threading to php, (for the cgi/cli stuff)..
The
Alan Knowles wrote:
Im looking at adding threading to php, (for the cgi/cli stuff)..
The story so far:
I've created an extension which diverts all zend_execute calls into the
extension - phpthreads_execute.
this function is a copy of zend_execute with a few modifications
- to copy
Shane,
I was in the Parrot session at OSCON and parrot is going to implement threads
in the exact same way. One interp per thread with sharing memory.
- brad
--- Shane Caraveo [EMAIL PROTECTED] wrote:
Alan Knowles wrote:
Im looking at adding threading to php, (for the cgi/cli stuff)..
Shane Caraveo wrote:
Alan Knowles wrote:
Im looking at adding threading to php, (for the cgi/cli stuff)..
The story so far:
I've created an extension which diverts all zend_execute calls into
the extension - phpthreads_execute.
this function is a copy of zend_execute with a few
26 matches
Mail list logo
