At 09:23 AM 10/1/2001 -0400, Michael Maraist wrote:
> > > Just because parrot knows what functions can croak, it
> > > doesn't mean that
> > > it can possibly know which locks have been taken out all
> > > the way back up
> > > the stack between the call to longjmp and the
> > > corresponding setj
At 04:15 PM 9/30/2001 -0400, Sam Tregar wrote:
>On Sun, 30 Sep 2001, Nick Ing-Simmons wrote:
>
> > The main problem with perl5 and threads is that threads are an
> afterthought.
>
>Which, of course, also goes for "UNIX and threads" and "C and threads".
>It's good for us to be thinking about as ea
On Sun, 30 Sep 2001, Nick Ing-Simmons wrote:
> The main problem with perl5 and threads is that threads are an afterthought.
Which, of course, also goes for "UNIX and threads" and "C and threads".
It's good for us to be thinking about as early as possible but it's no
garauntee that there won't be
--- Alan Burlison <[EMAIL PROTECTED]> wrote:
> Benjamin Stuhl wrote:
>
> > Let me be more specific: if you're holding a mutex over
> a
> > call back into parrot, it's your own fault. Parrot
> itself
> > knows which functions may croak() and which won't, so
> it
> > can use utility funtions that r
> > or have entered a muteX,
>
> If they're holding a mutex over a function call without a
> _really_ good reason, it's their own fault.
General perl6 code is not going to be able to prevent someone from
calling code that in-tern calls XS-code. Heck, most of what you do in
perl involves some sor
> 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.
At 05:23 PM 9/20/2001 -0400, Michael L Maraist wrote:
>There wasn't any code for CHECK_EVENTS w/in Parrot when I first read the
>source-code. I merely assumed that it's role was not-yet determined, but
>considered the possible uses. CHECK_EVENTS seems to be gone at the
>moment, so it's a moot
Arthur Bergman wrote:
> > 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
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
> >
> 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
17 matches
Mail list logo
