At 23:10 -0500 1/5/04, Gordon Henriksen wrote:
Data corruption unacceptable? I disagree. It depends on the contract
put forward by the language in question. Notably, Perl makes no such
guarantees thus far, being as how it doesn't (any longer) run in a
traditional threaded model. Successfully
At 23:10 -0500 1/5/04, Gordon Henriksen wrote:
Data corruption unacceptable? I disagree.
I get the feeling people just aren't reading what's been written, or
aren't keeping it all straight.
*User* and *program* data integrity is not our problem -- not only
are we not guaranteeing that, I'd be
On Sunday, January 4, 2004, at 03:17 , Jeff Clites wrote:
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().
On Sunday, January 4, 2004, at 01:43 , Dan Sugalski wrote:
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().
Gordon Henriksen wrote:
Dan Sugalski wrote:
An interpreter *must* lock any shared data structure,
including PMCs, when accessing them. Otherwise they may
be in an inconsistent state when being accessed, which will
lead to data corruption or process crashing, which is
unacceptable.
At 4:03 PM -0800 1/4/04, Damien Neil wrote:
It's my understanding that Parrot has chosen to take the path of using
many mutable data structures at the VM level; unfortunately, this is
pretty much incompatible with a fast or elegant threading model.
Yep, generally true. The choice was made on
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
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
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 clones
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.
In
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
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
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.
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 handle.
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 heavy
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 thread that
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
On Sat, 03 Jan 2004 01:48:07 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote:
ding! ding! ding! you just brought in a cpu specific instruction which
is not guaranteed to be on any other arch. in fact many have such a
beast but again, it is not accessible from c.
you can't bring x86 centrism into
Nigel Sandever writes:
Maybe it would be possible (for me + others) to write the core of a win32 specific,
threaded VM interpreter that would take parrot byte code and run it. Thereby,
utilising all the good stuff that preceeds the VM interpreter, plus probably large
chunks of the parrot VM,
Nigel Sandever [EMAIL PROTECTED] wrote:
[ Line length adjusted for readability ]
VIRTUAL MACHINE INTERPRETER
At any given point in the running of the interpreter, the VM register
set, program counter and stack must represent the entire state for
that thread.
That's exactly, what a
Nigel Sandever [EMAIL PROTECTED] wrote:
On Sat, 03 Jan 2004 01:48:07 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote:
your ideas make sense but only on redmond/intel which is not the target
space for parrot.
s/not the/by far not the only/
Maybe it would be possible (for me + others) to write
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT These are platform specific details. We will use whatever the
LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair.
LT The LOCK() can be any atomic operation and doesn't need to call the
LT kernel, if the lock is
At 12:15 -0500 1/3/04, Uri Guttman wrote:
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT These are platform specific details. We will use whatever the
LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair.
LT The LOCK() can be any atomic operation and doesn't need to
On Sat, 3 Jan 2004 11:35:37 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
Nigel Sandever [EMAIL PROTECTED] wrote:
VIRTUAL MACHINE INTERPRETER
At any given point in the running of the interpreter, the VM register
set, program counter and stack must represent the entire state for
At 18:20 + 1/3/04, Nigel Sandever wrote:
Sharing data between the threads/interpreters is implemented by
tieing the two copies of the variables to be shared and each time
a STORE is performed in one thread, the same STORE has too be
performed on the copy of that var held on every other
I'm trying to be constructive here. Some passages may appear to be
blunt. Read at your own risk ;-)
At 01:48 -0500 1/3/04, Uri Guttman wrote:
NS == Nigel Sandever [EMAIL PROTECTED] writes:
NS All that is required to protect an object from corruption through
NS concurrent access and
On Jan 3, 2004, at 11:19 AM, Elizabeth Mattijsen wrote:
At 01:48 -0500 1/3/04, Uri Guttman wrote:
NS == Nigel Sandever [EMAIL PROTECTED] writes:
NS All that is required to protect an object from corruption
through
NS concurrent access and state change is to prevent two (or more)
VMs
NS
On Jan 3, 2004, at 10:08 AM, Elizabeth Mattijsen wrote:
At 12:15 -0500 1/3/04, Uri Guttman wrote:
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT These are platform specific details. We will use whatever the
LT platform/OS provides. In the source code its a LOCK() UNLOCK()
pair.
LT
Nigel Sandever [EMAIL PROTECTED] wrote:
On Sat, 3 Jan 2004 11:35:37 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
That's exactly, what a ParrotInterpreter is: the entire state for a
thread.
This is only true if a thread == interpreter.
If a single interpreter can run 2 threads then that
EM == Elizabeth Mattijsen [EMAIL PROTECTED] writes:
ding! ding! ding! you just brought in a cpu specific instruction which
is not guaranteed to be on any other arch. in fact many have such a
beast but again, it is not accessible from c.
EM I just _can't_ believe I'm hearing this. So
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT Uri Guttman [EMAIL PROTECTED] wrote:
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT These are platform specific details. We will use whatever the
LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair.
LT The
EM == Elizabeth Mattijsen [EMAIL PROTECTED] writes:
EM At 12:15 -0500 1/3/04, Uri Guttman wrote:
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT These are platform specific details. We will use whatever the
LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair.
LT
On Sat, Jan 03, 2004 at 08:05:13PM +0100, Elizabeth Mattijsen wrote:
At 18:20 + 1/3/04, Nigel Sandever wrote:
Sharing data between the threads/interpreters is implemented by
tieing the two copies of the variables to be shared and each time
a STORE is performed in one thread, the same
On Jan 3, 2004, at 12:26 PM, Uri Guttman wrote:
LT These are platform specific details. We will use whatever the
LT platform/OS provides. In the source code its a LOCK() UNLOCK()
pair.
LT The LOCK() can be any atomic operation and doesn't need to call
the
LT kernel, if the lock is
On Sat, 3 Jan 2004 21:00:31 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
That's exactly, what a ParrotInterpreter is: the entire state for a
thread.
This is only true if a thread == interpreter.
If a single interpreter can run 2 threads then that single interpreter
cannot
JC == Jeff Clites [EMAIL PROTECTED] writes:
JC On Jan 3, 2004, at 12:26 PM, Uri Guttman wrote:
that could be workable and might be faster. it does mean that locks
are two step as well, user space test/set and fallback to kernel
lock. we can do what nigel said and wrap the test/set in
At 21:11 + 1/3/04, Dave Mitchell wrote:
On Sat, Jan 03, 2004 at 08:05:13PM +0100, Elizabeth Mattijsen wrote:
Actually, you can bless a reference to a shared variable, but you
can't share a blessed object (the sharing will let you lose the
content of the object). I think shared compound
Uri Guttman [EMAIL PROTECTED] wrote:
ok, i missed the 'if' there. :)
that could be workable and might be faster. it does mean that locks are
two step as well, user space test/set and fallback to kernel lock.
Yep, that is, what the OS provides. I really don't like to reinvent
wheels here -
Uri Guttman [EMAIL PROTECTED] wrote:
... this again brings up how we lock so
that GC/alloc will work properly with threads. do we lock a thread pool
but not the thread when we access a shared thingy?
This is the major issue, how to continue. Where are shared objects
living (alloc) and where
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 datastructure,
Why is it shared automatically? Do
Nigel Sandever [EMAIL PROTECTED] wrote:
On Sat, 3 Jan 2004 21:00:31 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
Yep. So if a single interpreter (which is almost a thread state) should
run two threads, you have to allocate and swap all.
When a kernel level thead is spawned, no
On Jan 3, 2004, at 2:59 PM, Leopold Toetsch wrote:
Nigel Sandever [EMAIL PROTECTED] wrote:
Only duplicating shared data on demand (COW) may work well on systems
that support COW in the kernel.
No, we are dealing with VM objects and structures here - no kernel is
involved for COWed copies of e.g.
On Thu, 01 Jan 2004 21:32:22 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote:
UG Uri Guttman
NS Nigel Sandever. (Mostly not reproduced here!)
NS REENTRANCY
UG this is true for c level threads but not necessarily true for VM level
UG threads. f the VM is atomic at its operation level and can't
NS == Nigel Sandever [EMAIL PROTECTED] writes:
NS ATOMICITY AND CRITICAL SECTIONS
UG that is what i mentioned above, disabling time slicing/ preemption when
UG desired. it is not just a win32 concept. hell, turning off interrupts
UG during interrupt handlers goes way back! redmond just
This is going to be extremely light on details with respect to the current state of
the Parrot interpreter.
It is also going to be expressed in terms of Win32 APIs.
For both of these I apologise in advance. Time, and the or forever hold your peace
imperative has overridden my desire to do
NS == Nigel Sandever [EMAIL PROTECTED] writes:
NS REENTRANCY
NS Not only must the VMI be coded in a reentrant fashion, with all state
NS addressed through pointers (references) loaded into it's Virtual
NS register set. All the code underlying it, including syscalls and CRT
NS must
46 matches
Mail list logo