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:
[ 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 <[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 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
48 matches
Mail list logo
