On Thu, 20 Sep 2001 14:04:43 -0700, Damien Neil wrote:
On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
For clarification: do you mean async I/O, or non-blocking I/O?
Async. When the interpreter issues a read, for example, it won't assume the
read completes immediately.
That
At 03:59 PM 9/20/2001 +0200, Arthur Bergman wrote:
While it has been decided that perl should be using ithread like
threading, I guess that is irelevant at the parrot level. Are you
going to have one virtual cpu per thread with it's own set of registers
or are you going to context switch the
AB == Arthur Bergman [EMAIL PROTECTED] writes:
AB In an effort to rest my braine from a coredumping perl5 I started
AB to think a bit on threading under parrot? While it has been
AB decided that perl should be using ithread like threading, I guess
AB that is irelevant at the parrot
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS I'm also seriously considering throwing *all* PerlIO code into separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals async i/o idea floating in my
DS I'm also seriously considering throwing *all* PerlIO code into
separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals async i/o idea floating in my numb skull. it is an
api that would
On Thu, Sep 20, 2001 at 12:33:54PM -0700, Hong Zhang wrote:
DS I'm also seriously considering throwing *all* PerlIO code into
separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals
Arthur Bergman wrote:
In an effort to rest my braine from a coredumping perl5 I started to think a bit on
threading under parrot?
While it has been decided that perl should be using ithread like threading, I guess
that is irelevant at the parrot level. Are you
going to have one virtual cpu
What we're going to do is fire up a new interpreter for each thread. (We
may have a pool of prebuilt interpreters hanging around for this
eventuality) Threading *is* essential at the parrot level, and there are
even a few (as yet undocumented) opcodes to deal with them, and some stuff
On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
What we're going to do is fire up a new interpreter for each thread. (We
may have a pool of prebuilt interpreters hanging around for this
eventuality) Threading *is* essential at the parrot level, and there are
even a
At 12:33 PM 9/20/2001 -0700, Hong Zhang wrote:
DS I'm also seriously considering throwing *all* PerlIO code into
separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals async i/o idea
At 04:36 PM 9/20/2001 -0400, Rocco Caputo wrote:
On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
What we're going to do is fire up a new interpreter for each thread. (We
may have a pool of prebuilt interpreters hanging around for this
eventuality) Threading *is*
At 01:53 PM 9/20/2001 -0700, Damien Neil wrote:
On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote:
Nope. Internal I/O, at least as the interpreter will see it is async. You
can build sync from async, it's a big pain to build async from sync.
Doesn't mean we actually get
Nope. Internal I/O, at least as the interpreter will see it is async. You
can build sync from async, it's a big pain to build async from sync.
Doesn't mean we actually get asynchrony, just that we can.
It is trivial to build async from sync, just using thread. Most Unix async
are built
DN == Damien Neil [EMAIL PROTECTED] writes:
DN On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
For clarification: do you mean async I/O, or non-blocking I/O?
Async. When the interpreter issues a read, for example, it won't assume the
read completes immediately.
At 02:04 PM 9/20/2001 -0700, Damien Neil wrote:
On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
For clarification: do you mean async I/O, or non-blocking I/O?
Async. When the interpreter issues a read, for example, it won't assume
the
read completes immediately.
That
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Might sound that way, but it isn't. What I'm talking about is
DS something like:
DS READ S3, P1, I0
DS X: SLEEP 3
DS EQ I0, 0, X
DS PRINT S3
DS Where we issue the read on the filehandle in P1, telling it to
DS store
16 matches
Mail list logo
