Re: [perl #55000] [PATCH] Threads Failures on Optimized Build

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 befo

[perl #55000] [PATCH] Threads Failures on Optimized Build

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.

Re: [perl #55000] Threads Failures on Optimized Build

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);

[perl #55000] Threads Failures on Optimized Build

# New Ticket Created by chromatic # Please include the string: [perl #55000] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55000 > I'm seeing several test failures from an optimized build (Ubuntu Hardy Heron x86 32-bit).

Dynamic binding (e.g. Perl5 "local"), continuations, and threads

can be used 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

Re: threads on Solaris aren't parallel?

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 cha

Re: threads on Solaris aren't parallel?

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 config/init/hints

Re: threads on Solaris aren't parallel?

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

Re: threads on Solaris aren't parallel?

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

Re: threads on Solaris aren't parallel?

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

threads on Solaris aren't parallel?

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

Re: threads

"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: threads

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

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

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

> 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

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

On 5/19/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Vladimir Lipsky <[EMAIL PROTECTED]> wrote: > > > Parrot_really_destroy needs to be fixed > > $verbose++ please, thanks > yes, please. until this issue is fixed, i'm rolling back these patches so

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

destroy needs to be fixed > > $verbose++ please, thanks > 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 th

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

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

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

Jerry Gay <[EMAIL PROTECTED]> wrote: > here's the patch to unskip test 6: Thanks, applied. leo

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

jerry gay <[EMAIL PROTECTED]> wrote: much better! one failing test now... D:\usr\local\parrot-HEAD\trunk>perl 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 ".\p

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

elow: D:\usr\local\parrot-HEAD\trunk>perl 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-HEAD\trunk\t\pmc\threads_4.pasm"":

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

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 thin

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

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 +++ parrot-devel/config/gen/platform/win

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

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. If you read the output that Jerry sent earlier, you would have seen that the thread doesn't ever reach to the print"thread\n

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

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 fr

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

), The last two pmc's are allocated from a place which is clearly not the pmc pool arena from which other pmc's are allocated. What's that? Out of pmc's? So another arena are allocated. Or something else?. Please run the test with the -d option set either (and send me personally

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

EMAIL PROTECTED]> wrote: > > the 'detatch' threads test hangs on win32. this small patch skips one > > Could you try the following code('the detatch' threads test with one tweak) > and tell me if it hangs either and what output you get? > > find_global P5, &q

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

the 'detatch' threads test hangs on win32. this small patch skips one Could you try the following code('the detatch' threads test with one tweak) and tell me if it hangs either and what output you get? find_global P5, "_foo" new P2, .ParrotThread find_method P0,

Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32

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

[perl #35305] [PATCH] skip threads 'detatch' test on win32

# New Ticket Created by jerry gay # Please include the string: [perl #35305] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=35305 > the 'detatch' threads test hangs on win32. this small patch skips one test,

Re: COND macros (was: Threads, events, Win32, etc.)

> 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 c

Re: COND macros (was: Threads, events, Win32, etc.)

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, whi

Re: COND macros (was: Threads, events, Win32, etc.)

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 a

Re: Threads, events, Win32, etc.

> [ 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

COND macros (was: Threads, events, Win32, etc.)

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)

Re: Threads, events, Win32, etc.

gnal gets converted to a global event 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

Re: Threads, events, Win32, etc.

simply implementing Win9x as a non-threaded > > platform. Of course, hopefully nobody will even ask... > > We'll see. But as Parrot's IO system is gonna be asynchronous in core, I > doubt that we'll support it. Obviously Parrot has to run on non-threaded platform

Re: Threads, events, Win32, etc.

f one thread doing signals. > And as for IO, I see the obvious advantages of performing synchronous > IO functions in a separate thread to make them asynchronous, but that > sounds like the job of a worker thread pool. There are many ways to > implement this, but serializing them all t

Re: Threads, events, Win32, etc.

this in > > the check_events functions. > > Not all. We need to do check_events() for e.g. message passing too. > > Win9x doesn't have async IO on files, so it still might > > require separate threads to do IOs. > > I'm not sure, if we even should support Win9{

Re: Threads, events, Win32, etc.

or the pthreads based 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) require

Re: Threads, events, Win32, etc.

plementation. > * 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 isn't a problem with Win32.

Threads, events, Win32, etc.

other object 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 t

Re: [Proposal] JIT, exec core, threads, and architectures

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 s

Re: [Proposal] JIT, exec core, threads, and architectures

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

Re: [Proposal] JIT, exec core, threads, and architectures

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

Re: [Proposal] JIT, exec core, threads, and architectures

). 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 be

Re: [Proposal] JIT, exec core, threads, and architectures

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

Re: [Proposal] JIT, exec core, threads, and architectures

table (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 co

Re: [Proposal] JIT, exec core, threads, and architectures

rce code. > ... 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 execution in the middle of one segment, e.g. after a

Re: [Proposal] JIT, exec core, threads, and architectures

;t have 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 mi

[Proposal] JIT, exec core, threads, and architectures

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

Re: Another Update to threads/IO problem on Cygwin

Cygwin list, but I asked one of the Cygwin knowledgeable monks 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/

Another Update to threads/IO problem on Cygwin

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 cygw

Re: Update to Threads/IO issue on Cygwin

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 upgr

Update to Threads/IO issue on Cygwin

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 p

Re: Threads on Cygwin

--- 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

Re: Threads on Cygwin

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 - de

Re: Threads on Cygwin

parrot/src/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 C @@ -125,7 +131,15 @@

Re: Threads on Cygwin

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 thre

Re: Threads on Cygwin

--- 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 varian

Re: Threads on Cygwin

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. S/

Re: Threads on Cygwin

--- 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 t

Re: Threads on Cygwin

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

Re: Threads on Cygwin

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

Re: Threads on Cygwin

--- 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

Re: Threads on Cygwin

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

Re: Threads on Cygwin

--- 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 > appl

Threads on Cygwin

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 fa

[perl #31651] [TODO] Win32 - Threads, Events, Signals, Sockets

# New Ticket Created by Will Coleda # Please include the string: [perl #31651] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=31651 > (No details. This comes from TODO.win32)

Re: As the world stops: of GC and threads

Gordon Henriksen wrote: So, I haven't heard any convincing evidence that execution in other threads can continue while garbage collection is executing, copying collector or not. So it is. The coyping GC is indeed a different issue and not related to DOD (our term - that is freeing

As the world stops: of GC and threads

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 h

Re: Threads... last call

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

Re: More on threads

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 loc

Re: More on threads

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 PMC*/dat

RE: More on threads

rather than with the PMC class. And if it's with the VTABLE, 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:

Re: More on threads

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 looked

Re: More on threads

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

RE: More on threads

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 cl

Re: More on threads

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 > is

RE: More on threads

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 h

Re: More on threads

At 1:47 AM + 1/25/04, Pete Lomax wrote: On Sat, 24 Jan 2004 13:59:26 -0500, Gordon Henriksen <[EMAIL PROTECTED]> wrote: 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. These rules ensure that dereferencing a pointer will

Threads. Again. Dammit.

n 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

Re: More on threads

on't have to guess whether the contents have issues with threads. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED]

Re: Threads... last call

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 is

Re: Threads... last call

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 lo

Re: Threads... last call

; 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 cr

Re: Threads... last call

cks 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 > >&qu

Re: Threads... last call

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

Re: Threads... last call

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 is limited to "surprising results" rather than

Re: More on threads

all locking is under our control, we can optimize it and it doesn't conflict or it shouldn't deadlock. > 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

Re: More on threads

l synchronization requirements. 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 at

Re: More on threads

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 si

Re: More on threads

Pete Lomax wrote: Gordon Henriksen wrote: 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. These rules ensure that dereferencing a pointer will not segfault. In this model, wouldn't catching the segfault and retrying (once

Re: More on threads

On Sat, 24 Jan 2004 13:59:26 -0500, Gordon Henriksen <[EMAIL PROTECTED]> wrote: >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. >These rules ensure that dereferencing a pointer will not segfault. In this model, wouldn't

Re: More on threads

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 re

Re: More on threads

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

Re: More on threads

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

Re: More on threads

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

More on threads

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 completely

RE: Threads... last call

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

  1   2   3   4   >