On Sun, Jun 1, 2008 at 1:31 PM, Vasily Chekalkin [EMAIL PROTECTED] wrote:
interp-exceptions initialized lazily. But really_destroy_exception have
signature with __attribute_notnull__. So we should either check this value
before function call or change function signature to accepts NULL.
I
On Tuesday 03 June 2008 10:50:27 NotFound via RT wrote:
On Sun, Jun 1, 2008 at 1:31 PM, Vasily Chekalkin [EMAIL PROTECTED] wrote:
interp-exceptions initialized lazily. But really_destroy_exception have
signature with __attribute_notnull__. So we should either check this
value before
chromatic wrote:
There is little bit different patch for it.
--- a/src/exceptions.c
+++ b/src/exceptions.c
@@ -772,7 +772,9 @@ associated exceptions free list for the specified
interpreter.
void
destroy_exception_list(PARROT_INTERP)
{
-really_destroy_exception_list(interp-exceptions);
# New Ticket Created by chromatic
# Please include the string: [perl #55000]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55000
I'm seeing several test failures from an optimized build (Ubuntu Hardy Heron
x86
to jump to an arbitrary call
frame without unwinding the stack.
Then there are threads to consider. The naive approach makes each
thread's dynamic bindings visible to all other threads, which may or may
not be desirable (not, IMHO, but this is a language design issue).
Worse, the final state
On Mon, Dec 12, 2005 at 10:28:31PM +0100, Leopold Toetsch wrote:
On Dec 12, 2005, at 17:53, Erik Paulson wrote:
Hi -
I'm using an older version of Parrot (0.2.2) so I can use threads.
It seems that Parrot on Solaris doesn't ever use more than one
processor
On Dec 13, 2005, at 19:35, Erik Paulson wrote:
I've got it to work now, thanks to Joe Wilson who gave me the last
clue.
Great.
I turned on pthreads in configure:
perl Configure.pl --ccflags=:add{ -pthreads -D_REENTERANT }
--linkflags=:add{ -pthreads }
Have a look at
Leopold Toetsch wrote:
and I changed the definitino of CREATE_THREAD_JOINABLE:
For a final patch you could include some #ifdef SOLARIS_VERSION == foo
to just include necessary extensions.
Doesn't look like there's anything Solaris-specific here. Other
non-Linux OSes will need the same
Hi -
I'm using an older version of Parrot (0.2.2) so I can use threads.
It seems that Parrot on Solaris doesn't ever use more than one processor.
The program attached should create argv[1] number of threads, and
divide up over both of them argv[2] - ie perfect linear speedup.
I've got a dual
On Dec 12, 2005, at 17:53, Erik Paulson wrote:
Hi -
I'm using an older version of Parrot (0.2.2) so I can use threads.
It seems that Parrot on Solaris doesn't ever use more than one
processor.
[ ... ]
Is there some way we can check to see if Parrot is actually creating
more than
one
Leopold Toetsch wrote:
There are AFAIK some issues with solaris (but I don't know the
details) It might need a different threading lib or some additional
init code to create 'real' threads.
You just have to know how they implement pthreads, which is
weasel-worded in POSIX and
allows Solaris
Dave Frost [EMAIL PROTECTED] wrote:
From the outset i decided i wanted the vm to provide its own threading
mechanism i.e. not based on posix threads for example.
Parrot had the option of providing its own threads, thread scheduling and
the like. As leo mentioned, we're using OS threads
hi all,
Im interested to know how perl6/parrot implements threads. Im mainly
interested as im writing a small vm of my own. Not a production vm like
parrot, more for interest/curiosity etc. From the outset i decided i
wanted the vm to provide its own threading mechanism i.e. not based
On Sep 27, 2005, at 17:14, Dave Frost wrote:
hi all,
Im interested to know how perl6/parrot implements threads.
*) based on OS threads
*) one interpreter per thread
*) STM for shared objects / atomicity
Any pointers, thoughts or comments are welcome.
Cheers
Dave
leo
Mr. Gay, let me know if you wait for a special request to uncomment the line
/*#include parrot/thr_windows.h*/
in config/gen/platform/win32/threads.h
whatever was broken, has now been fixed. patch applied, and ticket closed.
~jerry
yes, please. until this issue is fixed, i'm rolling back these patches
so the threads test 6 is again skipped on windows, and the 200-odd
failing tests will work again. feel free to send more patches, i'll
happily test them (more carefully next time) and work out the bugs
before applying.
patch
Vladimir Lipsky [EMAIL PROTECTED] wrote:
1) Why the heck
Easy: it's not in the MANIFEST. Why: patches scattered between inline
and attached and the MANIFEST part missing ... it's easy to overlook.
-# ifdef _MCS_VER1
+# ifdef _MCS_VER
Thanks, applied - hope that's really the whole thing
jerry gay [EMAIL PROTECTED] wrote:
much better! one failing test now...
D:\usr\local\parrot-HEAD\trunkperl t/harness t/pmc/threads.t
t/pmc/threadsok 3/11# Failed test (t/pmc/threads.t at line
163)
# got: 'start 1
# in thread
# done
# Can't spawn .\parrot.exe
D:\usr\local\parrot
Jerry Gay [EMAIL PROTECTED] wrote:
here's the patch to unskip test 6:
Thanks, applied.
leo
Vladimir Lipsky [EMAIL PROTECTED] wrote:
D:\usr\local\parrot-HEAD\trunk\t\pmc\threads_4.pasm' failed with
exit code 255
Parrot_really_destroy needs to be fixed
$verbose++ please, thanks
leo
As stated already, this (and possibly other thread) test(s) can't succeed
as long as Win32 has no event loop that passes the terminate event on to
the running interpreter.
1) Why the heck
--- parrot/config/gen/platform/win32/threads.h Mon May 2 14:40:59 2005
+++
Vladimir Lipsky wrote:
parrot (r8016): no change. hangs w/98% cpu. here's the -t output:
As stated already, this (and possibly other thread) test(s) can't
succeed as long as Win32 has no event loop that passes the terminate
event on to the running interpreter.
The last two pmc's are allocated
(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
etc
On 5/15/05, Vladimir Lipsky [EMAIL PROTECTED] wrote:
the 'detatch' threads test
Jerry Gay [EMAIL PROTECTED] wrote:
the 'detatch' threads test hangs on win32. this small patch skips one
test, so others may fail :)
Thanks, applied.
leo
# New Ticket Created by jerry gay
# Please include the string: [perl #35305]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35305
the 'detatch' threads test hangs on win32. this small patch skips one
test, so others
Parrot's locks will all have wait/signal/broadcast capabilities. We
should go rename the macros and rejig the code. This may have to wait
Really? I'm not sure I understand what broadcast does on a lock. Are
you talking about something like P5's condpair? If so, why not just
cop that code? Of
[ long win32 proposal ]
I've to read through that some more times.
OK; let me know if you have any questions on how the Win32 stuff
works. I tried to explain things that are unlike POSIX, but of course
it makes sense to me.
Do you alread have ideas for a common API, or where to split the
On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Gabe Schaffer [EMAIL PROTECTED] wrote:
The problem is a different one: the COND_INIT macro just passes a
condition location, the mutex is created in a second step, which isn't
needed for windows. OTOH a mutex aka
At 8:42 AM -0500 11/19/04, Gabe Schaffer wrote:
On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Gabe Schaffer [EMAIL PROTECTED] wrote:
The problem is a different one: the COND_INIT macro just passes a
condition location, the mutex is created in a second step, which
IO system is gonna be asynchronous in core, I
doubt that we'll support it.
Obviously Parrot has to run on non-threaded platforms where the kernel
threading and AIO stuff just won't work. You can still do user
threads, but file IO will still block everything.
rationale. I can understand why
and from there it can be
put into specifc threads if they have installed signal handlers for that
signal.
But as said the existing code is experimental and is likely to change a
lot.
I don't see why there needs to be a separate thread to listen for IOs
to finish. Can't that be the same thread
Gabe Schaffer [EMAIL PROTECTED] wrote:
Not quite. COND_WAIT takes an opaque type defined by the platform, that
happens to be a mutex for the pthreads based implementation.
It should, but it doesn't. Here's the definition:
# define COND_WAIT(c,m) pthread_cond_wait(c, m)
You are already
async IO on files, so it still might
require separate threads to do IOs.
I'm not sure, if we even should support Win9{8,5}.
I'd be happy with simply implementing Win9x as a non-threaded
platform. Of course, hopefully nobody will even ask...
Anyway, it seems to me that all this event/IO
through one queue sounds like
a bottleneck to me.
Yes. The AIO library is doing that anyway i.e. utilizing a thread pool
for IO operations.
Au contraire. Your analysis is precise. Do you like to take a shot at a
Win32 threads/event model? So we could figure out the necessary
splitting of API
to be associated with them. I think this
could be cleaned up with further abstraction.
* CLEANUP_PUSH doesn't have any Win32 analog that I know of, although
it's not clear why this might be needed for Parrot anyway. Right now
it just looks like it's used to prevent threads from abandoning a
mutex, which
analog that I know of, although
it's not clear why this might be needed for Parrot anyway. Right now
it just looks like it's used to prevent threads from abandoning a
mutex, which isn't a problem with Win32.
Yes. And it'll very likely go away. But anyway - it's a define by the
platform. So you
implementation.
Yep. This is important to note -- the joys of portability often means
that functions in the source carry parameters that might not actually
get used. That's the case here, since POSIX threads (which the unices
and VMS use for their threading model) requires a mutex. I fully
expect
Jeff Clites [EMAIL PROTECTED] wrote:
On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:
Nethertheless we have to create managed objects (a Packfile PMC) so
that we can recycle unused eval-segments.
True, and some eval-segments are done as soon as they run (eval 3 +
4), whereas others may
On Oct 19, 2004, at 1:56 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:
Nethertheless we have to create managed objects (a Packfile PMC) so
that we can recycle unused eval-segments.
True, and some eval-segments are done as soon
). Running
such a compiled piece of code with different threads would currently
do the wrong thing.
The correct constant table depends on the code segment, rather than the
specific interpreter, right?
Yes.
...That means that referencing the absolute
address of the const table entry would
On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:
Jeff Clites wrote:
On Oct 16, 2004, at 4:47 AM, Leopold Toetsch wrote:
Nethertheless we have to create managed objects (a Packfile PMC) so
that we can recycle unused eval-segments.
True, and some eval-segments are done as soon as they run (eval
, *all* but i386.
We do still re-JIT for each thread on PPC, though we wouldn't have to
(just never changed it to not).
Doing that or not depending on a specific JIT platform is error prone
and clutters the source code.
... But, we use this currently, because
there is one issue with threads
(and recycle it later, which is a different problem). Running such
a compiled piece of code with different threads would currently do the
wrong thing.
Access to constants in the constant table is not only a problem for the
JIT runcore, its a lengthy operation for all code, For a string constant
On Oct 16, 2004, at 12:26 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
... But, we use this currently, because
there is one issue with threads: With a thread, you don't start from
the beginning of the JITted code segment,
This isn't a threading issue. We can always start
to
(just never changed it to not). But, we use this currently, because
there is one issue with threads: With a thread, you don't start from
the beginning of the JITted code segment, but rather you need to
start with a specific Parrot function call, somewhere in the middle.
But you can't just jump
First some facts:
- all JIT platforms *except* i386 have a register reserved for the
runtime interpreter
- Parrot register addressing is done relative to that CPU register
- that would allow to reuse the JITted code for different threads
aka interpreters
- but because of i386 is using absolute
Since all the tests were passing in the past, I
decided to play the CVS game to find exactly when/what
changed.
Good news is - nothing to do with Parrot
Bad news is - it means it was an upgrade to Cygwin,
which I also do on a daily basis. I have no way of
tracking down what changed but I could
Joshua Gatcomb [EMAIL PROTECTED] wrote:
Since all the tests were passing in the past, I
decided to play the CVS game to find exactly when/what
changed.
Good news is - nothing to do with Parrot
Good, thanks for taking the time to investigate that.
Bad news is - it means it was an upgrade to
I happened to have found the last cygwin1.dll lying
around in /tmp that I kept as a backup. I swapped it
with the current cygwin1.dll just to see if it would
make the IO problem go away and much to my happy
surprise - it did.
Details:
cygwin1.dll-1.5.10-3 - previous stable build, works
great
at the
Monastery (http://www.perlmonks.org). They indicated
there was a major problem with 1.5.11-1 with threads
losing output (my problem exactly) and that it was
corrected with one of the latest snapshots
(http://cygwin.com/snapshots/). I downloaded it and
tried it - everything is working great.
make test
/inter_create.c Fri Oct 1 15:26:26 2004
+++ parrot-leo/src/inter_create.c Sat Oct 2 12:06:10 2004
@@ -31,6 +31,12 @@
#define ATEXIT_DESTROY
/*
+ * experimental: use shared IO resources for threads
+ */
+
+#define PARROT_SHARED_IO 1
+
+/*
=item Cstatic int is_env_var_set(const char* var
On Saturday 02 October 2004 12:49, Leopold Toetsch wrote:
Does this patch help?
No, it makes things worse:
--- without-patch.txt 2004-10-03 14:35:58.824775096 +0200
+++ with-patch.txt 2004-10-03 14:35:37.843964664 +0200
@@ -30,7 +30,12 @@
# expected: '500500
# 500500
# '
-ok 6 -
--- Jens Rieks [EMAIL PROTECTED] wrote:
On Saturday 02 October 2004 12:49, Leopold Toetsch
wrote:
Does this patch help?
No, it makes things worse:
Actually it doesn't. There is something wrong with
threads_6.pasm as my output for the test doesn't
change with or without the patch and yet
Joshua Gatcomb [EMAIL PROTECTED] wrote:
PIO_OS_UNIX is the one defined and now parrot squawks
Polly wanna Unix everytime I run it ;-)
Now what?
Fix the thread related IO bug? Seriously, I don't know yet, if the IO
initialization is done correctly for threads. Currently each thread has
its
Joshua Gatcomb [EMAIL PROTECTED] wrote:
... only 1 of the
two messages is displayed
I've fixed a flaw in the IO flush code. Please try again, thanks.
leo
Joshua Gatcomb [EMAIL PROTECTED] wrote:
I agree, but that doesn't explain why only 1 of the
two messages is displayed to the screen when the sleep
statement is present.
Overlooked that in the first place. So what you get is that the one *or*
the other string is displayed. That's a serious
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
Joshua Gatcomb [EMAIL PROTECTED] wrote:
... only 1 of the
two messages is displayed
I've fixed a flaw in the IO flush code. Please try
again, thanks.
Still not working, but thanks! The behavior has
changed a bit though.
Here is the behavior
Joshua Gatcomb [EMAIL PROTECTED] wrote:
After the change - case 3 now prints thread 1.
Strange.
You mentioned in the previous email that you were
interested in knowing if this was Windows IO or the
Cygwin variant. I would love to give you that
information, but color me clueless.
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
Joshua Gatcomb [EMAIL PROTECTED] wrote:
After the change - case 3 now prints thread 1.
Strange.
indeed
You mentioned in the previous email that you were
interested in knowing if this was Windows IO or
the
Cygwin variant. I would love
Joshua Gatcomb [EMAIL PROTECTED] wrote:
Up until a couple of weeks ago, all the threads tests
were passing on Cygwin. I had submitted a patch some
time ago that never got applied enabling tests for
threads, timer, and extend_13 that never got applied.
I figured there was good reason
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
Joshua Gatcomb [EMAIL PROTECTED]
wrote:
I had submitted a patch some time ago that never
got
applied enabling tests for threads, timer, and
extend_13.
Overlooked? Please rediff and resend.
I will do - likely tomorrow.
It says
Up until a couple of weeks ago, all the threads tests
were passing on Cygwin. I had submitted a patch some
time ago that never got applied enabling tests for
threads, timer, and extend_13 that never got applied.
I figured there was good reason so I didn't say
anything about the tests failing
--- Joshua Gatcomb [EMAIL PROTECTED]
wrote:
Up until a couple of weeks ago, all the threads
tests
were passing on Cygwin. I had submitted a patch
some
time ago that never got applied enabling tests for
threads, timer, and extend_13 that never got
applied.
I figured there was good reason
# New Ticket Created by Will Coleda
# Please include the string: [perl #31651]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31651
(No details. This comes from TODO.win32)
So, I haven't heard any convincing evidence that execution in other
threads can continue while garbage collection is executing, copying
collector or not. (Point of fact, the copying collector has nothing to
do with it.) So what are the options to stop the world? I've heard the
first 2
are a standard Java library of common data
structures such as arrays and hashes. Collections are not
synchronized; access involves no locks at all. Multiple threads
accessing the same collection at the same time cannot, however,
result in the virtual machine crashing. (They can result in
data
the contents have
issues with threads.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
with in the interaction between strings and threads (I thought we
could dodge that, but, well... I was wrong).
This needs more thought and more work before we go anywhere. Some of
the obvious stuff, like fixing up the cache slot of the PMC, should
be done regardless.
I also think we need more real-worldish tests
At 1:47 AM + 1/25/04, Pete Lomax wrote:
On Sat, 24 Jan 2004 13:59:26 -0500, Gordon Henriksen
[EMAIL PROTECTED] wrote:
snip
It doesn't matter if an int field could read half of a double or v.v.;
it won't crash the program. Only pointers matter.
snip
These rules ensure that dereferencing a
Dan Sugalski wrote:
Gordon Henriksen wrote:
Leopold Toetsch wrote:
Gordon Henriksen wrote:
... Best example: morph. morph must die.
Morph is necessary. But please note: morph changes the vtable of
the PMC to point to the new data types table. It has nothing to do
Dan Sugalski [EMAIL PROTECTED] wrote:
[ PObj union ]
Still, point taken. That needs to die and it needs to die now. For
the moment, lets split it into two pieces, a buffer pointer and an
int/float union, so we don't have to guess whether the contents have
issues with threads.
The Buffer
Leopold Toetsch wrote:
Gordon Henriksen wrote:
... in the multi-thousand-
line-diff it was, yet. :( Else you'd have the patch already
1) *no* multi-thousands line diffs
2) what is the problem, you like to solve?
Er? Extending to the rest of the source tree the huge patch to
classes
Gordon Henriksen wrote:
Er? Extending to the rest of the source tree the huge patch to
classes which you already applied. No logic changes; just
cleaning those PObj accessor macros up.
Ah sorry, that one. Please send in small bunches, a few files changed at
once.
leo
Gordon Henriksen wrote:
Hm. Well, both are a discriminator, then; dispatch to code which
presumes the contents of the union is quite frequently done without
examining the flags.
The flags are *never* consulted for a vtable call in classes/*. DOD does
different things if a Buffer or PMC is
,
then it doesn't need to be traced. (But, then, all PObjs don't have
VTABLES...)
Sidebar:
If we're looking at lock-free concurrency, flag updates probably have
to be performed with atomic 's and |'s. BUT: Doesn't apply during GC,
since other threads will have to be stalled then.
Do any PMC
Gordon Henriksen wrote:
Leopold Toetsch wrote:
No, flags are mutable and per PMC *not* per class.
Of course there are flags which must remain per-PMC. I wasn't
referring to them. Sorry if that wasn't clear.
If a flag is only saying my VTABLE methods use the UnionVal as {a
void*/a PObj*/a
Leopold Toetsch [EMAIL PROTECTED] wrote:
[ perlscalar moprh ]
But that can be solved by first clearing str_val, then changing the
vtable.
Fixed. I currently don't see any more problems related to perscalars.
PerlStrings are unsafe per se, as long as we have the copying GC. They
need a lock
On Wednesday, January 28, 2004, at 12:53 , Melvin Smith wrote:
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
Java Collections are a standard Java library of common data structures
such as arrays and hashes. Collections are not synchronized; access
involves no locks at all. Multiple threads
On Wed, Jan 28, 2004 at 12:53:09PM -0500, Melvin Smith wrote:
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
Java Collections are a standard Java library of common data structures
such as arrays and hashes. Collections are not synchronized; access
involves no locks at all. Multiple threads
; access
involves no locks at all. Multiple threads accessing the same
collection at the same time cannot, however, result in the virtual
machine crashing. (They can result in data structure corruption, but
this corruption is limited to surprising results rather than VM crash
Melvin Smith [EMAIL PROTECTED] wrote:
I thought we were discussing correct behavior of a shared data structure,
not general cases. Or maybe this is the general case and I should
go read more backlog? :)
Basically we have three kinds of locking:
- HLL user level locking [1]
- user level
structures such as arrays and hashes. Collections are not
synchronized; access involves no locks at all. Multiple threads
accessing the same collection at the same time cannot, however,
result in the virtual machine crashing. (They can result in data
structure corruption, but this corruption
Gordon Henriksen [EMAIL PROTECTED] wrote:
I overstated when I said that morph must die. morph could live IF:
[ long proposal ]
Increasing the union size, so that each pointer is distinct is not an
option. This imposes considerable overhead on a non-threaded program
too, due its bigger PMC
.
If these are the two options, I as a user would rather have a separate
threaded parrot executable which takes the 2.1% hit, rather than the
400% overhead as per above. It's easily the difference between usable
threads and YAFATTP (yet another failed attempt to thread perl).
Gordon Henriksen
[EMAIL PROTECTED]
% hit, rather than the
400% overhead as per above. It's easily the difference between usable
threads and YAFATTP (yet another failed attempt to thread perl).
All these numbers are by far too premature, to have any impact on RL
applications.
Please note, that even with a 400% slowdown for one vtable
Gordon Henriksen [EMAIL PROTECTED] wrote:
... Best example: morph. morph must die.
Morph is necessary. But please note: morph changes the vtable of the PMC
to point to the new data types table. It has nothing to do with a typed
union.
Gordon Henriksen
leo
On Saturday, January 24, 2004, at 09:23 , Leopold Toetsch wrote:
Gordon Henriksen [EMAIL PROTECTED] wrote:
... Best example: morph. morph must die.
Morph is necessary. But please note: morph changes the vtable of the
PMC to point to the new data types table. It has nothing to do with a
typed
Leopold Toetsch wrote:
Gordon Henriksen [EMAIL PROTECTED] wrote:
... Best example: morph. morph must die.
Morph is necessary. But please note: morph changes the vtable of the
PMC to point to the new data types table. It has nothing to do with a
typed union.
I overstated when I said that morph
I wrote:
With this vocabulary:
variable: A memory location which is reachable (i.e., not
garbage). [*]
pointer: The address of a variable.
pointer variable: A variable which contains a pointer.
access: For a pointer p, any dereference of p*p, p-field, or
p[i]whether for the purposes of
On Sat, 24 Jan 2004 13:59:26 -0500, Gordon Henriksen
[EMAIL PROTECTED] wrote:
snip
It doesn't matter if an int field could read half of a double or v.v.;
it won't crash the program. Only pointers matter.
snip
These rules ensure that dereferencing a pointer will not segfault.
In this model,
Pete Lomax wrote:
Gordon Henriksen wrote:
snip
It doesn't matter if an int field could read half of a double or v.v.;
it won't crash the program. Only pointers matter.
snip
These rules ensure that dereferencing a pointer will not segfault.
In this model, wouldn't catching the segfault and
-world
performance difference is between acquiring multiple locks per VM
operation (current Parrot proposal) vs. having a single lock
controlling all data access (Python) or jettisoning OS threads
entirely in favor of VM-level threading (Ruby). This forfeits the
ability to take advantage of multiple
access (Python) or jettisoning OS threads
entirely in favor of VM-level threading (Ruby). This forfeits the
ability to take advantage of multiple CPUs--but Leopold's initial
timing tests of shared PMCs were showing a potential 3-5x slowdown
from excessive locking.
I've seen software before
Dan Sugalski wrote:
At 5:24 PM -0500 1/22/04, Deven T. Corzine wrote:
Damian's issues were addressed before he brought them up, though not
in one spot.
A single global lock, like python and ruby use, kill any hope of
SMP-ability.
Hand-rolled threading has unpleasant complexity issues, is a
.
An existence proof:
Java Collections are a standard Java library of common data structures
such as arrays and hashes. Collections are not synchronized; access
involves no locks at all. Multiple threads accessing the same
collection at the same time cannot, however, result in the virtual
machine crashing
On Fri, 23 Jan 2004 10:24:30 -0500, [EMAIL PROTECTED] (Dan Sugalski) wrote:
If you're accessing shared data, it has
to be locked. There's no getting around that. The only way to reduce
locking overhead is to reduce the amount of data that needs locking.
One slight modification I would make
Deven T. Corzine wrote:
The most novel approach I've seen is the one taken by Project UDI
(Uniform Driver Interface).
This is very much the ithreads model which has been discussed. The
problem is that, from a functional perspective, it's not so much
threading as it is forking.
--
Gordon
Just thought I'd share some more thoughts on threading. I don't think
the threading proposal is baked, yet, unfortunately.
I've come to agree with Dan: As the threading requirements and the
architecture stand, parrot requires frequent and automatic locking to
prevent crashes. This is
Last chance to get in comments on the first half of the proposal. If
it looks adequate, I'll put together the technical details
(functions, protocols, structures, and whatnot) and send that off for
abuse^Wdiscussion. After that we'll finalize it, PDD the thing, and
get the implementation in
a single lock
controlling all data access (Python) or jettisoning OS threads
entirely in favor of VM-level threading (Ruby). This forfeits the
ability to take advantage of multiple CPUs--but Leopold's initial
timing tests of shared PMCs were showing a potential 3-5x slowdown
from excessive locking
1 - 100 of 297 matches
Mail list logo
