At 08:31 AM 9/27/00 +0100, Simon Cozens wrote:
>On Wed, Sep 27, 2000 at 02:40:27AM -0400, Dan Sugalski wrote:
> > I don't much care how its faked (if it is) as long as it works.
>
>Well, given that line disciplines means we have to write our own IO
>subsystem, can't we fake it ourselves?
If we w
At 08:59 AM 9/27/00 +0100, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > I don't much care how its faked (if it is) as long as it
> > works. Might not be as efficient as full kernel support for async
> > I/O, but it'll do. At least there'
On Wed, Sep 27, 2000 at 04:24:05AM -0400, Uri Guttman wrote:
> well, my question then is how does solaris do it? it can't be done with
> user level libs alone. what system calls does it use? undocumented ones
> perhaps with the libs as the public api?
> i finally found how solaris does its AIO un
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I can't see any reference to threads in the Solaris manual pages
TH> either. Certainly Unixware does:
TH> I thought that using threads was the standard SVR4 implementation
TH> but maybe Solaris has moved away from that.
well, my q
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I don't much care how its faked (if it is) as long as it
> works. Might not be as efficient as full kernel support for async
> I/O, but it'll do. At least there's some overlap. (You can get
> better device request or
In message <[EMAIL PROTECTED]>
Uri Guttman <[EMAIL PROTECTED]> wrote:
> now what bothers me is that all those calls are in section 3 and are no
> section 2 system calls. maybe it is faked with threads but i haven't
> found any support for that notion. if so, i wonder if we can actually
>
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> On Wed, Sep 27, 2000 at 02:40:27AM -0400, Dan Sugalski wrote:
>> I don't much care how its faked (if it is) as long as it works.
SC> Well, given that line disciplines means we have to write our own
SC> IO subsystem, can't we fak
On Wed, Sep 27, 2000 at 02:40:27AM -0400, Dan Sugalski wrote:
> I don't much care how its faked (if it is) as long as it works.
Well, given that line disciplines means we have to write our own IO subsystem,
can't we fake it ourselves?
--
"They laughed at Columbus, they laughed at Fulton, the
At 11:53 PM 9/26/00 -0400, Uri Guttman wrote:
>now what bothers me is that all those calls are in section 3 and are no
>section 2 system calls. maybe it is faked with threads but i haven't
>found any support for that notion. if so, i wonder if we can actually
>use it and not collide with perl thre
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> Certainly I know Unixware used to fake it up by creating a new
TH> thread and doing sync IO in that thread, and I think Solaris did
TH> the same but that was a couple of years ago now so things might
TH> be better now.
solaris has
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What'd be a larger win would be if we have async I/O built into the core
> I/O subsystem. That way we could queue up requests for blocks of data
> (whatever data we want, in this case bytecode) and have them fetche
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> Just a point of information: Windows 95/98 can NOT do asynch
>> IO...I've just spent the last week researching this, and that fact is
>> clearly and frequently scattered through the MSDN documentation. You can
>> fake AIO by usin
At 08:16 PM 9/26/00 +0100, Simon Cozens wrote:
>On Tue, Sep 26, 2000 at 02:04:58PM -0400, Dan Sugalski wrote:
> > What'd be a larger win would be if we have async I/O built into the core
> > I/O subsystem. That way we could queue up requests for blocks of data
> > (whatever data we want, in this c
On Tue, Sep 26, 2000 at 02:04:58PM -0400, Dan Sugalski wrote:
> What'd be a larger win would be if we have async I/O built into the core
> I/O subsystem. That way we could queue up requests for blocks of data
> (whatever data we want, in this case bytecode) and have them fetched while
> we're p
At 11:26 AM 9/26/00 -0700, Dave Storrs wrote:
>On Tue, 26 Sep 2000, Dan Sugalski wrote:
>
> > What'd be a larger win would be if we have async I/O built into the core
> > ...
> > This is reasonably simple on Unices that support it, as well as on VMS and
> > Windows. Can't speak for other platfor
On Tue, 26 Sep 2000, Dan Sugalski wrote:
> What'd be a larger win would be if we have async I/O built into the core
> ...
> This is reasonably simple on Unices that support it, as well as on VMS and
> Windows. Can't speak for other platforms, but I'm not hugely worried that
> we won't get th
At 05:35 PM 9/25/00 -0400, Michael Maraist wrote:
> > Ordered bytecode
> >
> > Bytecode should be structured in such a way that reading and executing
> > it can be parallelised.
> >
>
>Are you suggesting a threaded VM? I know that the core is being rewritten,
>so it's a possibility. If this is t
On Mon, Sep 25, 2000 at 05:35:09PM -0400, Michael Maraist wrote:
> In general, however, I don't see bytecode reading as being the real
> bottle-neck.
Quoting Nick Ing-Simmons in
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg01122.html:
"I have had similar doubts for some
> Ordered bytecode
>
> Bytecode should be structured in such a way that reading and executing
> it can be parallelised.
>
Are you suggesting a threaded VM? I know that the core is being rewritten,
so it's a possibility. If this is the case, then you'll want to reference
some of the other RFC's
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Ordered bytecode
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 310
Version: 1
Status: Developing
=head1 ABSTRACT
Bytecod
20 matches
Mail list logo
