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,
Following Leo's recent changes, several tests have been failing under
Fedora due to exec-shield, so I have gone ahead and committed the
mem_alloc_executable functions, based on Jonathan's rewrite of my
original patch.
Note that mem_alloc_executable now takes interpreter; this is only
actually
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
Peter Gibbs [EMAIL PROTECTED] wrote:
Log:
Prevent attempts to reallocate mmap'd executable memory until somebody
works out how to do it.
For linux/fedora, I'd go with this scheme:
- mem_alloc_executable uses valloc() that is memalign(getpagesize(),
size) with size rounded up to
Leopold Toetsch [EMAIL PROTECTED] wrote:
I'll check in a test if malloced memory is executable RSN.
The check is in. On fedora, the Configure line of JIT should have
(has_exec_protect yes)
If that's ok, some define in a header should be set.
We currently seem to be missing a general
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24796]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24796
Adding a hints file for solaris solves two thread-related link issues.
--
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24797]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24797
nci_test.c included malloc.h which is deprecated on FreeBSD (and
elsewhere
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24799]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24799
chartype_create_from_mapping() (called from the op find_chartype) fails
to
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
I was seeing an error in the second test in t/src/list.t on FreeBSD:
set_integer_keyed() not implemented in class 'PerlInt'
I tracked it down to two consecutive calls to pmc_new() returning the
same pointer, which is generally not what you want. Copying the
following line from imcc/main.c
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
Lars Balker Rasmussen wrote (via RT)
chartype_create_from_mapping() (called from the op find_chartype)
fails
to notice that it has run out of file, so happily parses the last line
twice. This leads to writing to array[-1]...
-if (line[0] != '#') {
+if (p *p != '#') {
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
Lars Balker Rasmussen [EMAIL PROTECTED] wrote:
According to #parrot, libnci.so is built automatically on some
platforms, but not on my FreeBSD.
No, its currently not built automatically.
- are you supposed to build libnci.so by hand if you want to test nci?
Yep. AFAIK are we lacking a
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
First, I'm not paying much attention. Maybe next week. However, as
messages that Eudora tags with multiple chiles tend to get my
attention, be aware that the following are non-negotiable:
1) We are relying on OS services for all threading constructs
We are not going to count on 'atomic'
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24802]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24802
Following the file reading bug in chartype.c, I checked the rest of
parrot
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
Dan Sugalski [EMAIL PROTECTED] wrote:
2) The only thread constructs we are going to count on are:
*) Abstract, non-recursive, simple locks
*) Rendezvous points (Things threads go to sleep on until another
thread pings the condition)
*) Semaphores (in the I do a V and P operation,
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...
Why not have the threads that share everything share interpreters. We
can have
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 Sat, 2004-01-03 at 17:24, Matt Fowles wrote:
I have a naive question:
Why must each thread have its own interpreter?
~handwavy, high-level answer~
For the same reason each thread in C, for example, needs its own stack
pointer.
Since Parrot's a register machine, each thread needs its own
On Jan 3, 2004, at 5:24 PM, Matt Fowles wrote:
All~
I have a naive question:
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 per-thread, since
At 1:11 AM +0100 1/4/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
2) The only thread constructs we are going to count on are:
*) Abstract, non-recursive, simple locks
*) Rendezvous points (Things threads go to sleep on until another
thread pings the condition)
*)
At 11:42 PM + 1/3/04, Nigel Sandever wrote:
03/01/04 23:20:17, Dan Sugalski [EMAIL PROTECTED] wrote:
[Dan getting cranky snipped]
And that was that! Sorry I spoke.
I'm not trying to shut anyone down. What I wanted to do was stop
folks diving down too low a level. Yes, we could roll our own
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS (This is one of those cases where I'd really prefer for force
DS everyone doing thread work to have to work on 8 processor Alpha
DS boxes (your choice of OS, I don't care), one of the most vicious
DS threading enviroments ever devised, but
At 11:49 PM -0500 1/3/04, Uri Guttman wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS (This is one of those cases where I'd really prefer for force
DS everyone doing thread work to have to work on 8 processor Alpha
DS boxes (your choice of OS, I don't care), one of the most vicious
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 11:49 PM -0500 1/3/04, Uri Guttman wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS (This is one of those cases where I'd really prefer for force
DS everyone doing thread work to have to work on 8 processor Alpha
DS boxes
45 matches
Mail list logo
