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
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
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
--- 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
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
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
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.
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()
--- 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
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
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
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.
--
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
26 matches
Mail list logo
