Matt Fowles wrote:
I understand if this suggestion is dismissed for violating the rules,
but I would like an answer to the question simply because I do not know
the answer.
The most admiral reason for asking a question and I doubt it will be
dismissed.
H
At 00:49 +0100 1/4/04, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> Indeed. But as soon as there is something special such as a
datastructure external to Perl between threads (which happens
automatically "shared" automatically, because Perl doesn't know about
> the d
Hello,
I have some questions about which part of the actual headers are
internal, which ones are for embedders and which ones are for
extenders.
AFAIR nothing but Parrot sources should #include parrot/parrot.h.
The public interface is available through parrot/embed.h and
parrot/extend.h. Corre
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed automatically
by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise. Shouldn't even be
pursued.
Atomic guarantees on collections
On Sat, Jan 03, 2004 at 08:24:06PM -0500, Matt Fowles wrote:
> All~
>
> I have a naive question:
>
> Why must each thread have its own interpreter?
>
>
> I understand that this suggestion will likely be disregarded because of
> the answer to the above question. But here goes anyway...
>
> Wh
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Jan 3, 2004, at 5:24 PM, Matt Fowles wrote:
>> Why must each thread have its own interpreter?
> The short answer is that the bulk of the state of the virtual machine
> (including, and most importantly, its registers and register stacks)
> needs to be pe
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Why not have the threads that share everything share interpreters. We
> can have these threads be within the a single interpreter thus
> eliminating the need for complicated GC locking and resource sharing
> complexity. Because all of these threads will b
Mattia Barbon <[EMAIL PROTECTED]> wrote:
> AFAIR nothing but Parrot sources should #include parrot/parrot.h.
> The public interface is available through parrot/embed.h and
> parrot/extend.h. Correct?
Yep. But by far not all necessary interface functions & types are done.
> Mattia
leo
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> When you use an external library in Perl, such as e.g. libxml, you
> have Perl data-structures and libxml data-structures. The Perl
> data-structures contain pointers to the libxml data-structures.
> In comes the starting of an ithread and Perl cl
At 14:47 +0100 1/4/04, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> When you use an external library in Perl, such as e.g. libxml, you
have Perl data-structures and libxml data-structures. The Perl
> data-structures contain pointers to the libxml data-structures.
> I
Dan Sugalski wrote:
Let us know either way -- if upgrading gcc works then we're going to
have to figure out how RH/GCC2.96 is breaking things so we can make it
not happen. :(
I have now upgraded gcc to 3.3.2 and I am getting the same error. We are
still freezing during test.
I have also noticed
At 11:59 PM -0500 1/3/04, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise. Shouldn't ev
Its a bit complicated and brain-mangling, the more in the absence of any
examples, but the current design in pdd16 seems to lack some flexibility
and is IMHO missing the proper handling of the (library-provided)
external_data. The latter will be passed to the Sub somehow, but what then?
Here is
Harry Jackson <[EMAIL PROTECTED]> wrote:
> Can someone tell me if there is an error in the code below.
The code is fine.
> it repeatedly from the command line it sometimes freezes ie it prints
> the contents of the array and then just stops and I need to do a CTRL-C
> to get back to the command
At 8:19 PM +0100 1/4/04, Leopold Toetsch wrote:
Its a bit complicated and brain-mangling, the more in the absence of
any examples, but the current design in pdd16 seems to lack some
flexibility and is IMHO missing the proper handling of the
(library-provided) external_data. The latter will be pa
On Jan 4, 2004, at 5:47 AM, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
When you use an external library in Perl, such as e.g. libxml, you
have Perl data-structures and libxml data-structures. The Perl
data-structures contain pointers to the libxml data-structures.
In
At 12:05 PM -0800 1/4/04, Jeff Clites wrote:
On Jan 4, 2004, at 5:47 AM, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
When you use an external library in Perl, such as e.g. libxml, you
have Perl data-structures and libxml data-structures. The Perl
data-structures contain
Leopold Toetsch wrote:
Harry Jackson <[EMAIL PROTECTED]> wrote:
Can someone tell me if there is an error in the code below.
The code is fine.
it repeatedly from the command line it sometimes freezes ie it prints
the contents of the array and then just stops and I need to do a CTRL-C
to get ba
On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise. Shouldn't
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> And don't forget the libraries that are picky about which thread calls
DS> into them -- there are some that require that the thread that created
DS> the handle for the library be the thread that calls into the library
DS> with that
On Sat, 03 Jan 2004 20:51, Luke Palmer wrote;
> Parrot is platform-independent, but that doesn't mean we can't
> take advantage of platform-specific instructions to make it faster
> on certain machines. Indeed, this is precisely what JIT is.
> But a lock on every PMC is still pretty hea
I think some of the massive back and forth that's going on is in part
due to terminology problems, which are in part causing some
conceptual problems. So, for the moment, let's agree on the following
things:
*) MUTEX - this is a low level, under the hood, not exposed to users,
thing that can b
At 3:17 PM -0500 1/4/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> And don't forget the libraries that are picky about which thread calls
DS> into them -- there are some that require that the thread that created
DS> the handle for the library be the threa
At 9:27 AM +1300 1/5/04, Sam Vilain wrote:
On Sat, 03 Jan 2004 20:51, Luke Palmer wrote;
> Parrot is platform-independent, but that doesn't mean we can't
> take advantage of platform-specific instructions to make it faster
> on certain machines. Indeed, this is precisely what JIT is.
> B
On Sun, 04 Jan 2004 17:53, Dan Sugalski wrote;
> Given that it's not a SMP, massively out of order NUMA system with
> delayed writes... no. 'Fraid not.
Sorry to be pedantic, but I always thought that the NU in NUMA implied
a contradiction of the S in SMP!
"NUMA MP" or "SMP", what does it me
At 10:01 AM +1300 1/5/04, Sam Vilain wrote:
On Sun, 04 Jan 2004 17:53, Dan Sugalski wrote;
> Given that it's not a SMP, massively out of order NUMA system with
> delayed writes... no. 'Fraid not.
Sorry to be pedantic, but I always thought that the NU in NUMA implied
a contradiction of the S in
Dave Mitchell wrote:
On Sat, Jan 03, 2004 at 08:24:06PM -0500, Matt Fowles wrote:
All~
I have a naive question:
Why must each thread have its own interpreter?
I understand that this suggestion will likely be disregarded because of
the answer to the above question. But here goes anyway...
On Jan 4, 2004, at 1:58 PM, Matt Fowles wrote:
Dave Mitchell wrote:
Why on earth would they be all one kernel-level thread?
Truth to tell I got the idea from Ruby. As I said it make
syncronization easier, because the interpreter can dictate when
threads context switch, allowing them to only
On Sun, 4 Jan 2004 15:47:35 -0500, [EMAIL PROTECTED] (Dan Sugalski) wrote:
> *) INTERPRETER - those bits of the Parrot_Interp structure that are
> absolutely required to be thread-specific. This includes the current
> register sets and stack pointers, as well as security context
> information.
This release fixes a few bugs and introduces the concept of runs in the
database whereby data for tests are stored separately and merged later
when needed. I'm hoping this will speed things up somewhat.
- Actually include do test.
- Create run concept in database.
- Belatedly remove check for
On Mon, 05 Jan 2004 10:13, Dan Sugalski wrote;
[...]
> these things. It's a set of 8 4-processor nodes with a fast
> interconnect between them which functions as a 32 CPU system. The
> four processors in each node are in a traditional SMP setup with a
> shared memory bus, tightly coup
On Sun, Jan 04, 2004 at 12:17:33PM -0800, Jeff Clites wrote:
> What are these standard techniques? The JVM spec does seem to guarantee
> that even in the absence of proper locking by user code, things won't
> go completely haywire, but I can't figure out how this is possible
> without actual loc
On Mon, 05 Jan 2004 12:58, Nigel Sandever wrote;
> Everything else, were my attempts at solving the requirements of
> synchronisation that this would require, whilst minimising the
> cost of that synchronisation, by avoiding the need for a mutex on
> every shared entity, and the costs of a
05/01/04 01:22:32, Sam Vilain <[EMAIL PROTECTED]> wrote:
[STUFF] :)
In another post you mentions intel hyperthreading.
Essentially, duplicate sets of registers within a single CPU.
Do these need to apply lock on every machine level entity that
they access?
No.
Why not?
Because they can only
Nigel Sandever writes:
> Whilst the state of higher level objects, that the machine level
> objects are a part of, may have their state corrupted by two
> threads modifying things concurrently. The state of the threads
> (registers sets+stack) themselves cannot be corrupted.
I'm going to ask fo
On Mon, 05 Jan 2004 15:43, Nigel Sandever wrote;
> I accept that it may not be possible on all platforms, and it may
> be too expensive on some others. It may even be undesirable in the
> context of Parrot, but I have seen no argument that goes to
> invalidate the underlying premise.
I th
36 matches
Mail list logo
