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 fi
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 thr
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
> > una
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().
Com
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().
C
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 purpos
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
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
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
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
> "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 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
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
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 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
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
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
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
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
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.
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 dup
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
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 wher
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
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 da
> "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
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
> > c
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 aq
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 s
> "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
> "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() UNL
> "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 he
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
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()
pai
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 LOCK() can be any atomic operation and does
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)
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 acce
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 thre
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 stat
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'
> "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 lo
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
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 Par
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 V
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 i
> "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! r
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 c
> "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
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 ot
49 matches
Mail list logo
