Re: Thread Question and Suggestion -- Matt

2004-01-04 Thread Harry Jackson
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Elizabeth Mattijsen
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

Extendiers interface

2004-01-04 Thread Mattia Barbon
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Gordon Henriksen
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

Re: Thread Question and Suggestion -- Matt

2004-01-04 Thread Dave Mitchell
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

Re: Thread Question and Suggestion -- Matt

2004-01-04 Thread Leopold Toetsch
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

Re: Thread Question and Suggestion -- Matt

2004-01-04 Thread Leopold Toetsch
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

Re: Extendiers interface

2004-01-04 Thread Leopold Toetsch
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Leopold Toetsch
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Elizabeth Mattijsen
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

Re: Problem during "make test"

2004-01-04 Thread Harry Jackson
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Dan Sugalski
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

NCI callback functions

2004-01-04 Thread Leopold Toetsch
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

Re: Problem during "make test"

2004-01-04 Thread Leopold Toetsch
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

Re: NCI callback functions

2004-01-04 Thread Dan Sugalski
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Jeff Clites
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Dan Sugalski
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

Re: Problem during "make test"

2004-01-04 Thread Harry Jackson
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Jeff Clites
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Uri Guttman
> "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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Sam Vilain
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

Threads: Time to get the terminology straight

2004-01-04 Thread Dan Sugalski
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Dan Sugalski
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Dan Sugalski
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

Re: Thread notes

2004-01-04 Thread Sam Vilain
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

Re: Thread notes

2004-01-04 Thread Dan Sugalski
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

Re: Thread Question and Suggestion -- Matt

2004-01-04 Thread Matt Fowles
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...

Re: Thread Question and Suggestion -- Matt

2004-01-04 Thread Jeff Clites
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

Re: Threads: Time to get the terminology straight

2004-01-04 Thread Nigel Sandever
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.

[ANNOUNCE] Devel::Cover 0.32

2004-01-04 Thread Paul Johnson
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

Re: Thread notes

2004-01-04 Thread Sam Vilain
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

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Damien Neil
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

Re: Threads: Time to get the terminology straight

2004-01-04 Thread Sam Vilain
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

Re: Threads: Time to get the terminology straight

2004-01-04 Thread Nigel Sandever
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

Re: Threads: Time to get the terminology straight

2004-01-04 Thread Luke Palmer
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

Re: Threads: Time to get the terminology straight

2004-01-04 Thread Sam Vilain
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