Re: new event loop
Thus spake the enlightened Uri Guttman [EMAIL PROTECTED]:
i am going to make a proposal that we ('we' to be defined
later) develop
a new common event loop with two major goals in mind:
1. the event loop should be fully portable over all
modern unix OS's
and the win32 server flavors (nt, 2k).
VMS! We must have VMS! Oh, and it should proabably be
modular enough that one can use a stripped down version of
it to write Palm apps too. (Perl6 for the TI-89, anyone?)
-- BKS
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: new event loop
At 05:29 AM 7/5/2001 -0700, Benjamin Stuhl wrote:
Thus spake the enlightened Uri Guttman [EMAIL PROTECTED]:
i am going to make a proposal that we ('we' to be defined
later) develop
a new common event loop with two major goals in mind:
1. the event loop should be fully portable over all
modern unix OS's
and the win32 server flavors (nt, 2k).
VMS! We must have VMS! Oh, and it should proabably be
modular enough that one can use a stripped down version of
it to write Palm apps too. (Perl6 for the TI-89, anyone?)
VMS is actually easy here--it has a sane async I/O system to build on. It's
the various Unices that are a pain.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
PDD 4, v1.3 Perl's internal data types (Final version)
'Kay, here's the final version of this.
Cut here
=head1 TITLE
Perl's internal data types
=head1 VERSION
1.3
=head2 CURRENT
Maintainer: Dan Sugalski [EMAIL PROTECTED]
Class: Internals
PDD Number: 4
Version: 1.3
Status: Developing
Last Modified: 02 July 2001
PDD Format: 1
Language: English
=head2 HISTORY
=over 4
=item Version 1.3, 2 July 2001
=item Version 1.2, 2 July 2001
=item Version 1.1, 2 March 2001
=item Version 1, 1 March 2001
=back
=head1 CHANGES
=item Version 1.3
Fixed some silly typos and dropped phrases.
Took all the underscores out of the field names.
=item Version 1.2
The string header format has changed some to allow for type
tagging. The flags information for strings has changed as well.
=item Version 1.1
INT and NUM are now concepts rather than data structures, as making
them data structures was a Bad Idea.
=item Version 1
None. First version
=head1 ABSTRACT
This PDD describes perl's known internal data types.
=head1 DESCRIPTION
This PDD details the primitive datatypes that the perl core knows how
to deal with. These types are lower-level than what's presented to the
perl programmer.
=head1 IMPLEMENTATION
=head2 Integer data types
Integer data types are generically referred to as CINTs. CINTs are
conceptual things, and there is no data structure that corresponds to them.
=over 4
=item Platform-native integer
These are whatever size native integer was chosen at perl
configuration time. The C-level typedef CIV and CUV get you a
platform-native signed and unsigned integer respectively.
=item Arbitrary precision integers
Big integers, or bigints, are arbitrary-length integer numbers. The
only limit to the number of digits in a bigint is the lesser of the
amount of memory available or the maximum value that can be
represented by a CUV. This will generally allow at least 4 billion
digits, which ought to be far more than enough for anyone.
The C structure that represents a bigint is:
struct bigint {
void *buffer;
UV length;
IV exponent;
UV flags;
}
=begin question
Should we scrap the buffer pointer and just tack the buffer on the end
of the structure? Saves a level of indirection, but means if we need
to make the buffer bigger we have to adjust anything pointing to it.
=end question
The Cnum_buffer pointer points to the buffer holding the actual
number, Clength is the length of the buffer, Cexponent is the base
10 exponent for the number (so 2e4532 doesn't take up much space), and
Cflags are some flags for the bigint.
BNote:The flags and exponent fields may be generally unused, but are
in to make the base structure identical in size and field types to
other structures. They may be removed before the first release of perl
6.
=back
=head2 Floating point data types
Floating point data types are generically reffered to as CNUMs. Like
CINTs, CNUMs are a conceptual things, not a real data structure.
=over 4
=item Platform native float
These are whatever size float was chosen when perl was configured. The
C level typedef CNV will get you one of these.
=item Arbitrary precision decimal numbers
Arbitrary precision decimal numbers, or bignums, can have any number
of digits before and after the decimal point. They are represented by
the structure:
struct bignum {
void *buffer;
UV length;
IV exponent;
UV flags;
}
and yes, this looks identical to the bigint structure. This isn't
accidental. Upgrading a bigint to a bignum should be quick.
=for question
Like the bigint structure, should we toss the data pointer and just
tack the data on the end?
=end question
=back
=head2 String data types
Perl has a single internal string form:
struct perl_string {
void *buffer;
UV allocated;
UV bytes;
UV flags;
UV characters;
UV encoding;
UV type;
UV unused;
}
The fields are:
=over 4
=item buffer
Pointer to the start of the string's data.
=item allocated
How many bytes are allocated in the buffer.
=item bytes
How many bytes are used in the buffer.
=item flags
Flags indicating whatever. Bits 0-15 are reserved for perl, bits 16-23
for the encoding/decoding code, and teh rest for the type code.
=item characters
How many characters are in the buffer. An optional cache field.
=item encoding
How the data is encoded, for example fixed 8-bit characters, utf-8, or
utf-32. An index into the encoding/decoding function table. Note that
this specifies encoding only--it's valid to encode EBCDIC characters
with the utf-8 algorithm. Silly, but valid.
=item type
What sort of string data is in the buffer, for example ASCII, EBCDIC,
or Unicode. Used to index into the table of string functions.
=item unused
Filler. Here to make sure we're both exactly double the size of a
bigint/bigfloat header and to make sure we don't cross cache lines on
any modern processor.
=back
=head1
Between-Opcode Callbacks
Here's a feature suggestion for Perl 6. It would be nice to be able to tell the interpreter to call a user-defined C function between opcodes. This could make it easier to implement debuggers, profilers, etc. as well as providing a method of safely using asynchronous callbacks that certain C libraries like to use. Of course, if you guys already have a better scheme in mind, don't let me stop you. :-) - D [EMAIL PROTECTED]
RE: new event loop
UG == Uri Guttman ([EMAIL PROTECTED]) writes: UG it looks pretty powerful which is one reason it may not be good to use UG in perl. we don't expect to be doing CORBA level stuff in the core. :) That wasn't what I had in mind either, but since Perl6 is, as far as I understand it, going to be a rewrite of most of the perl core I thought (IMHO) that taking a look at something that has been successfully used in real-time applications to solve the problem at hand could be a good idea. ACE is also fairly well documented, and there exists a number of tutorials - among them http://www.cs.wustl.edu/~schmidt/PDF/ACE-tutorial.pdf I think the Active Object pattern presented at page 58 might illustrate to what extent the ACE library can be used to both multiplex, demultiplex and possibly serialize, marshall and unmarshall events between threads and possibly processes. I think that Perl sooner or later will support cross process calls, and the event dispatching mechanism will at that point have to take this into account. That is: a call from a process p1 to another process p2 can result in a call from p2 to p1 before the original call to p2 finally returns to p1. This only means two things: - The event dispatching mechanism should be extensible - The event dispatching mechanism should support recursive calls This way both CORBA and other RPC mechanisms can be added to Perl6 through packages in an elegant manner. Since Perl6 is going to be multithreaded, I think it makes sence to borrow at least some of the design patterns implemented in ACE. UG perl6's event loop will need to be tightly integrated with the op UG dispatch loop and possibly some other critical subsystems. IMHO: the ACE_Reactor (in Reactor.h) provides just this kind of functionality, and it integrates well with just about any event generating subsystem. The following classes implements various kinds of Reactors: - ACE_Select_Reactor - ACE_XtReactor - ACE_WFMO_Reactor - ACE_Msg_WFMO_Reactor ACE_Reactor is an event demultiplexing mechanism, which IMHO illustrates how the such a mechanism could be implemented in Perl6. UG also the memory management scheme we use may not be compatible UG with the c++ one in ACE. One of the neat things about ACE is that you can use just about any memory management scheme you want to. UG ACe doesn't seem to support async file i/o but we can add that on our UG own. i think having a common api over all the different async file i/o UG api's will be very popular. we can do this in the perl5 event module. ACE does support async file io through the descendants of classes found in Asynch_IO_Impl.h and Proactor.h. This currently (to my knowledge) only works on Win32 platforms and on platforms supporting POSIX aio calls. Best regards Espen Harlinn Senior Engineer, Software Seamos AS - mailto: [EMAIL PROTECTED] Phone: +47 55 22 07 81 Fax:+47 85 02 29 43 Address: Stokkedalslia 5 5155 BØNES NORWAY -
