Re: SV: Parrot multithreading?

2001-10-01 Thread Dan Sugalski
At 04:15 PM 9/30/2001 -0400, Sam Tregar wrote: On Sun, 30 Sep 2001, Nick Ing-Simmons wrote: The main problem with perl5 and threads is that threads are an afterthought. Which, of course, also goes for UNIX and threads and C and threads. It's good for us to be thinking about as early as

Re: SV: Parrot multithreading?

2001-10-01 Thread Dan Sugalski
At 09:23 AM 10/1/2001 -0400, Michael Maraist wrote: Just because parrot knows what functions can croak, it doesn't mean that it can possibly know which locks have been taken out all the way back up the stack between the call to longjmp and the corresponding setjmp. And, under

RE: SV: Parrot multithreading?

2001-09-29 Thread Michael Maraist
or have entered a muteX, If they're holding a mutex over a function call without a _really_ good reason, it's their own fault. General perl6 code is not going to be able to prevent someone from calling code that in-tern calls XS-code. Heck, most of what you do in perl involves some sort of

Re: SV: Parrot multithreading?

2001-09-29 Thread Benjamin Stuhl
--- Alan Burlison [EMAIL PROTECTED] wrote: or have entered a mutex, If they're holding a mutex over a function call without a _really_ good reason, it's their own fault. Rubbish. It is common to take out a lock in an outer functions and then to call several other functions

Re: SV: Parrot multithreading?

2001-09-28 Thread David M. Lloyd
On Fri, 28 Sep 2001, Alan Burlison wrote: Arthur Bergman wrote: longjmp in a controlled fashion isn't thread-safe? Or longjmping while holding mutexs and out from asynchronous handlers is not thread-safe? Arthur It *may* be possible to use longjmp in threaded programs in a restricted

Re: SV: Parrot multithreading?

2001-09-28 Thread Dan Sugalski
At 01:03 PM 9/28/2001 -0500, David M. Lloyd wrote: On Fri, 28 Sep 2001, Alan Burlison wrote: Arthur Bergman wrote: longjmp in a controlled fashion isn't thread-safe? Or longjmping while holding mutexs and out from asynchronous handlers is not thread-safe? Arthur It *may* be

Re: SV: Parrot multithreading?

2001-09-28 Thread Benjamin Stuhl
Thus did the Illustrious Dan Sugalski [EMAIL PROTECTED] write: Croak's going to throw an interpreter exception. There's a little bit of documentation about the exception handling opcodes in docs/parrot_assembly.pod, with more to come soonish. This is fine at the target language level (e.g.

RE: SV: Parrot multithreading?

2001-09-28 Thread Hong Zhang
This is fine at the target language level (e.g. perl6, python, jako, whatever), but how do we throw catchable exceptions up through six or eight levels of C code? AFAICS, this is more of why perl5 uses the JMP_BUF stuff - so that XS and functions like sv_setsv() can Perl_croak()

RE: SV: Parrot multithreading?

2001-09-28 Thread Benjamin Stuhl
--- Hong Zhang [EMAIL PROTECTED] wrote: This is fine at the target language level (e.g. perl6, python, jako, whatever), but how do we throw catchable exceptions up through six or eight levels of C code? AFAICS, this is more of why perl5 uses the JMP_BUF stuff - so that XS and

RE: SV: Parrot multithreading?

2001-09-28 Thread Hong Zhang
This is the wrong assumption. If you don't care about the call stack, how can you expect the [sig]longjmp can successfully unwind stack? The caller may have a malloc memory block, Irrelevant with a GC. Are you serious? Do you mean I can not use malloc in my C code? or have entered

Re: SV: Parrot multithreading?

2001-09-28 Thread Alan Burlison
or have entered a mutex, If they're holding a mutex over a function call without a _really_ good reason, it's their own fault. Rubbish. It is common to take out a lock in an outer functions and then to call several other functions under the protection of the lock. The alternative is

Re: SV: Parrot multithreading?

2001-09-28 Thread Alan Burlison
Benjamin Stuhl wrote: Again, having a GC makes things easier - we clean up anything we lost in the GC run. If they don't actually work (are there any platforms where they don't work?), we can always write our own ;-). I eagerly await your design for a mutex and CV garbage collector. --

Re: SV: Parrot multithreading?

2001-09-28 Thread Dan Sugalski
At 11:56 PM 9/28/2001 +0100, Alan Burlison wrote: or have entered a mutex, If they're holding a mutex over a function call without a _really_ good reason, it's their own fault. Rubbish. It is common to take out a lock in an outer functions and then to call several other functions

Re: SV: Parrot multithreading?

2001-09-25 Thread Bryan C . Warnock
On Monday 24 September 2001 11:54 am, Dan Sugalski wrote: Odds are you'll get per-op event checking if you enable debugging, since the debugging oploop will really be a generic check event every op loop that happens to have the pending debugging event bit permanently set. Dunno whether

Re: SV: Parrot multithreading?

2001-09-24 Thread Uri Guttman
DS == Dan Sugalski [EMAIL PROTECTED] writes: do we always emit one in loops? DS At least one per statement, probably more for things like regexes. what about complex conditional code? i don't think there is an easy way to guarantee events are checked with inserted op codes.

Re: SV: Parrot multithreading?

2001-09-24 Thread Michael Maraist
Odds are you'll get per-op event checking if you enable debugging, since the debugging oploop will really be a generic check event every op loop that happens to have the pending debugging event bit permanently set. Dunno whether we want to force this at compile time or consider some way to

Re: SV: Parrot multithreading?

2001-09-24 Thread Michael Maraist
then what about a win/win? we could make the event checking style a compile time option. Odds are you'll get per-op event checking if you enable debugging, since the debugging oploop will really be a generic check event every op loop that happens to have the pending debugging event bit

Re: SV: Parrot multithreading?

2001-09-24 Thread Dan Sugalski
At 12:27 PM 9/24/2001 -0400, Michael Maraist wrote: then what about a win/win? we could make the event checking style a compile time option. Odds are you'll get per-op event checking if you enable debugging, since the debugging oploop will really be a generic check event every op loop

Re: SV: Parrot multithreading?

2001-09-24 Thread Uri Guttman
DS == Dan Sugalski [EMAIL PROTECTED] writes: then what about a win/win? we could make the event checking style a compile time option. DS Odds are you'll get per-op event checking if you enable debugging, DS since the debugging oploop will really be a generic check event DS every op

Re: SV: Parrot multithreading?

2001-09-24 Thread David M. Lloyd
On Mon, 24 Sep 2001, Uri Guttman wrote: then what about a win/win? we could make the event checking style a compile time option. DS Odds are you'll get per-op event checking if you enable debugging, DS since the debugging oploop will really be a generic check event DS every op

Re: SV: Parrot multithreading?

2001-09-24 Thread Bryan C . Warnock
On Monday 24 September 2001 11:54 am, Dan Sugalski wrote: Odds are you'll get per-op event checking if you enable debugging, since the debugging oploop will really be a generic check event every op loop that happens to have the pending debugging event bit permanently set. Dunno whether we

Re: SV: Parrot multithreading?

2001-09-21 Thread Dan Sugalski
At 09:07 PM 9/20/2001 -0400, Uri Guttman wrote: DS == Dan Sugalski [EMAIL PROTECTED] writes: DS There probably won't be any. The current thinking is that since DS the ops themselves will be a lot smaller, we'll have an explicit DS event checking op that the compiler will liberally

SV: Parrot multithreading?

2001-09-20 Thread Arthur Bergman
Arthur Bergman wrote: In an effort to rest my braine from a coredumping perl5 I started to think a bit on threading under parrot? While it has been decided that perl should be using ithread like threading, I guess that is irelevant at the parrot level. Are you going to have one

Re: SV: Parrot multithreading?

2001-09-20 Thread Michael L Maraist
Arthur Bergman wrote: Arthur Bergman wrote: In an effort to rest my braine from a coredumping perl5 I started to think a bit on threading under parrot? While it has been decided that perl should be using ithread like threading, I guess that is irelevant at the parrot level. Are

Re: SV: Parrot multithreading?

2001-09-20 Thread Dan Sugalski
At 05:23 PM 9/20/2001 -0400, Michael L Maraist wrote: There wasn't any code for CHECK_EVENTS w/in Parrot when I first read the source-code. I merely assumed that it's role was not-yet determined, but considered the possible uses. CHECK_EVENTS seems to be gone at the moment, so it's a moot

Re: SV: Parrot multithreading?

2001-09-20 Thread Uri Guttman
DS == Dan Sugalski [EMAIL PROTECTED] writes: DS There probably won't be any. The current thinking is that since DS the ops themselves will be a lot smaller, we'll have an explicit DS event checking op that the compiler will liberally scatter through DS the generated code. Less overhead