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 immediatel
> "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
> you can't do non-blocking i/o on files without aio_read type calls. but
> what dan is saying is that the api the interpreter uses internally will
> be an async one. it will either use native/POSIX aio calls or simulate
> that with sync calls and callbacks or possibly with threads.
>
That sound
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.
> "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 complete
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 sounds like what I would call non-blocking I/O. Asy
> 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
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 asy
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 asynchrony, just that we can.
For clarification: do you
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) Thread
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
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
> >
>
>
> 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
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 "virtu
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 tha
> 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
> "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 floa
> "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 th
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 t
19 matches
Mail list logo
