> "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 proc
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 m
> "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 d
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
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)
*)
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 i
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 o
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.
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 these
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 operati
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
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24802]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24802 >
Following the file reading bug in chartype.c, I checked the rest of
parrot for
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' operati
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
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 c
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
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 != '#') {
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'
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 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 lo
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24799]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24799 >
chartype_create_from_mapping() (called from the op find_chartype) fails
to noti
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24797]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24797 >
nci_test.c included which is deprecated on FreeBSD (and
elsewhere I assume), w
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #24796]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24796 >
Adding a hints file for solaris solves two thread-related link issues.
--
Lars
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 solu
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 t
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
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 need
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
46 matches
Mail list logo
