ugging threading issues using Dawa --
https://git.sr.ht/~bduggan/raku-dawa#multiple-threads
https://raku.land/cpan:BDUGGAN/Dawa
Perhaps stopping the threads and then stepping through statements
in each one can help to hone in on the race.
Brian
Briefly
I have lots of tests that individually run with no fails, but when run
together I get a really strange run-time error:
MoarVM oops: insert conflict, java is 437938227, 9 != 17
I think too many threads are being used.
I'm not asking someone else to solve this problem, bu
Oh, great! I was running the latest version I saw
listed in 'rakudobrew list-available' which is 2018.10:
~ $ perl6 -v
This is Rakudo version 2018.10 built on MoarVM version 2018.10
implementing Perl 6.c.
thanks!
Brian
On Saturday, November 10, Elizabeth Mattijsen wrote:
> In v6.d
In v6.d this throws the exception:
$ 6 'start die("bye"); sleep 1'
Unhandled exception in code scheduled on thread 4
bye
in code at -e line 1
whereas the exception is silently ignored in 6.c:
$ 6 'use v6.c; start die("bye"); sleep 1'
Not sure if this answers your question, as it is unclear
Hi Perl 6 Users,
What's the best way to know that an exception
occurred in another thread, e.g.
$ perl6 -e 'start say("hi"); sleep 1'
hi
$
but
$ perl6 -e 'start die("bye"); sleep 1'
$
I thought maybe $*SCHEDULER.uncaught_handler
would help out here, but it didn't seem to.
, :in, :out, :bin;
> > > > my $input = ("a" x 100).encode;
> > > > my $promise = start {
> > > > $proc.in.write: $input;
> > > > $proc.in.close;
> > > > }
> > > > say $proc.out.slurp-rest(:close, :bin).bytes;
>
On Thu, 12 Oct 2017 13:35:27 -0700, barto...@gmx.de wrote:
> On Sat, 23 Sep 2017 12:28:53 -0700, barto...@gmx.de wrote:
> > 3) Feeding the EvalServer with a program that calls 'run' (or
> > Proc::Async directly) does heavily leak memory, threads and what not
> > (ag
On Thu, 12 Oct 2017 13:35:27 -0700, barto...@gmx.de wrote:
> On Sat, 23 Sep 2017 12:28:53 -0700, barto...@gmx.de wrote:
> > 3) Feeding the EvalServer with a program that calls 'run' (or
> > Proc::Async directly) does heavily leak memory, threads and what not
> > (ag
Thanks for taking the time to look into this! I can't reproduce it with
that snippet, even if I make the file nonempty. But I can reproduce it with
the following two snippets. (I could not reproduce when I populated the
input file in the same script that does the await loop.)
perl6 -e '"$*TMPDIR/R
Oh, and when the list of filenames is the simpler `"$*TMPDIR/RT132447.test"
xx 100`, the problem also appears, but it seemed to take many more
iterations to crash. That could be just chance, though.
On Sat, Nov 18, 2017 at 4:01 PM Dan Zwell wrote:
> Thanks for taking the time to look into this!
Oh, and when the list of filenames is the simpler `"$*TMPDIR/RT132447.test"
xx 100`, the problem also appears, but it seemed to take many more
iterations to crash. That could be just chance, though.
On Sat, Nov 18, 2017 at 4:01 PM Dan Zwell wrote:
> Thanks for taking the time to look into this!
Thanks for taking the time to look into this! I can't reproduce it with
that snippet, even if I make the file nonempty. But I can reproduce it with
the following two snippets. (I could not reproduce when I populated the
input file in the same script that does the await loop.)
perl6 -e '"$*TMPDIR/R
On Fri, 17 Nov 2017 09:26:10 -0800, d...@zwell.net wrote:
> After more careful checking, I found the bug fix did make it into the
> October release. A bisect showed it was fixed it in
> commit 6af44f8d38a02bbd0d68cfd014165d6e33e4d89a.
> [...]
> Slurping on the file handle you described still produc
On Fri, 17 Nov 2017 09:26:10 -0800, d...@zwell.net wrote:
> After more careful checking, I found the bug fix did make it into the
> October release. A bisect showed it was fixed it in
> commit 6af44f8d38a02bbd0d68cfd014165d6e33e4d89a.
> [...]
> Slurping on the file handle you described still produc
problem. Can you close the bug
> > report?
> > Thanks!
> >
> > On Wed, Nov 15, 2017 at 2:59 AM perl6 via RT > follo...@perl.org>
> > wrote:
> >
> > > Greetings,
> > >
> > > This message has been automatically generated in response to t
problem. Can you close the bug
> > report?
> > Thanks!
> >
> > On Wed, Nov 15, 2017 at 2:59 AM perl6 via RT > follo...@perl.org>
> > wrote:
> >
> > > Greetings,
> > >
> > > This message has been automatically generated in response to t
on of a trouble ticket regarding:
> > "IO.slurp throws exception when run in threads",
> > a summary of which appears below.
> >
> > There is no need to reply to this message right now. Your ticket has
> > been
> > assigned an ID of [perl #132447].
> >
>
se to the
> creation of a trouble ticket regarding:
> "IO.slurp throws exception when run in threads",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket has been
> assigned an ID of [perl #132447].
>
> Pl
se to the
> creation of a trouble ticket regarding:
> "IO.slurp throws exception when run in threads",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket has been
> assigned an ID of [perl #132447].
>
> Pl
# New Ticket Created by Dan Zwell
# Please include the string: [perl #132447]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132447 >
The exception is:
Cannot assign to an immutable value in method slurp at
SETTING::src/core/
Hi,
Having trouble reproducing this on Linux on 2017.10-177-g77048b6 in a dir with
33k files that have one line of text each.
- Can you inlcude the exact version (perl6 -v) to go with the --ll-exception
stack trace so we can examine the referenced core code? I tried following the
line numbers
Hi,
Having trouble reproducing this on Linux on 2017.10-177-g77048b6 in a dir with
33k files that have one line of text each.
- Can you inlcude the exact version (perl6 -v) to go with the --ll-exception
stack trace so we can examine the referenced core code? I tried following the
line numbers
o/rakudo/pull/1004
After an "await" on a managed (non-main) thread it appears that execution
may continue on a different thread than it began on; however, $*THREAD
continues to report the same ID, so that multiple concurrent threads are
reporting the same thread ID.
Here's a scrip
on a different thread than it began on; however, $*THREAD
> continues to report the same ID, so that multiple concurrent threads
> are
> reporting the same thread ID.
>
> Here's a script that demonstrates the issue 50% of the time. This
> starts
> three promises, which
on a different thread than it began on; however, $*THREAD
> continues to report the same ID, so that multiple concurrent threads
> are
> reporting the same thread ID.
>
> Here's a script that demonstrates the issue 50% of the time. This
> starts
> three promises, which
se` line and never finishes:
> > >
> > > my $proc = run «cat -», :in, :out, :bin;
> > > my $input = ("a" x 100).encode;
> > > my $promise = start {
> > > $proc.in.write: $input;
> > > $proc.in.close;
> > > }
> > >
n the `.in.close` line and never finishes:
> >
> > my $proc = run «cat -», :in, :out, :bin;
> > my $input = ("a" x 100).encode;
> > my $promise = start {
> > $proc.in.write: $input;
> > $proc.in.close;
> > }
> > say $proc.out.slurp
n;
> my $input = ("a" x 100).encode;
> my $promise = start {
> $proc.in.write: $input;
> $proc.in.close;
> }
> say $proc.out.slurp-rest(:close, :bin).bytes;
> await $promise;
>
For now, if using threads, stick with Proc::Async (in the future, we&#x
ve an error as other handles across threads do?
you get the same behaviour with
https://rt.perl.org/Public/Bug/Display.html?id=129787
Note that without the `start` (i.e. when writing to `.in` and then
reading from `.out` in the same thread), it already hangs on the
`.in.w
Tests:
https://github.com/perl6/roast/commit/0705a6ea62a6f1cdaeb6cd46f3130d3728c4ce1b
On Tue, Oct 11, 2016 at 9:26 PM Lloyd Fournier
wrote:
> looks like it's been fixed! \o/
>
> I will put writing test for this on my TODO.
>
>
> On Tue, Oct 11, 2016 at 5:00 AM Sam S. via RT <
> perl6-bugs-follo.
looks like it's been fixed! \o/
I will put writing test for this on my TODO.
On Tue, Oct 11, 2016 at 5:00 AM Sam S. via RT
wrote:
All the examples in this thread work fine for me, on 64bit Linux with
current Rakudo.
This is Rakudo version 2016.09-163-g92c0921 built on MoarVM version
2016.
p to that
point (and I know how to do it, just didn't get to it yet).
> If you want to push to an array from multiple
> threads, you probably should use a Channel, or use Supplies with an
> .act block.
Or re-think your problem in a less imperative way. :-)
> In any case,
>
As far as I understand Jonathan’s position on this, is that you shouldn’t do
that. If you want to push to an array from multiple threads, you probably
should use a Channel, or use Supplies with an .act block.
As to the security implications of this behaviour, I must admit I haven’t
thought
On Mon, Aug 08, 2016 at 12:25:52AM -0700, Aleks-Daniel Jakimenko-Aleksejev
wrote:
> While it is probably a bad idea to push values into the same array from two
> threads, if I recall correctly rakudo is supposed to not crash like that no
> matter what.
>
> Code:
> my @a;
>
ray from two
threads, if I recall correctly rakudo is supposed to not crash like that no
matter what.
Code:
my @a;
start loop { @a.push: rand };
start loop { @a.push: rand };
sleep 1
Result:
“corrupted double-linked list”, or “double free or corruption”, or “.realloc():
invalid next size”, etc. Usua
On Thu Jul 28 09:58:56 2016, mt1...@gmail.com wrote:
> Thanks very much for your work, I'll wait and see. I pull rakudo
> versions directly from the github and some day it will be working :-).
>
The version bumps have been done. I've also added tests along the lines of your
examples to the specte
On 07/28/2016 03:00 PM, Jonathan Worthington via RT wrote:
On Fri, Jul 22, 2016 at 10:46 AM, mt1957 via RT <
perl6-bugs-follo...@perl.org> wrote:
I'm afraid the test I've created still hangs in rakudo version
2016.07.1-37-g60f256d built on MoarVM version 2016.07-3-gc01472d
implementing Perl 6.c
On Fri, Jul 22, 2016 at 10:46 AM, mt1957 via RT <
perl6-bugs-follo...@perl.org> wrote:
> I'm afraid the test I've created still hangs in rakudo version
> 2016.07.1-37-g60f256d built on MoarVM version 2016.07-3-gc01472d
> implementing Perl 6.c.
>
> That's still a too old MoarVM version. You'd need
On Fri Jul 22 01:46:53 2016, mt1...@gmail.com wrote:
> I'm afraid the test I've created still hangs in rakudo version
> 2016.07.1-37-g60f256d built on MoarVM version 2016.07-3-gc01472d
> implementing Perl 6.c.
>
Ah, that's a too early MoarVM version to have the fix (it was the commit after
that o
ion 2016.07-3-gc01472d
implementing Perl 6.c.
This time only 80 threads started and using '$r += [+] $i, 3, 4, 5, 6,
7, 8, 9, 10;' in the critical section.
Btw, a problem in [+] might exist because changing that into '$r += $i +
3 + 4 + 5 + 6 + 7 + 8 + 9 + 10;' the code is
ion 2016.07-3-gc01472d
implementing Perl 6.c.
This time only 80 threads started and using '$r += [+] $i, 3, 4, 5, 6,
7, 8, 9, 10;' in the critical section.
Btw, a problem in [+] might exist because changing that into '$r += $i +
3 + 4 + 5 + 6 + 7 + 8 + 9 + 10;' the code is running flawlessly even
with 4000 threads.
Greetings,
Marcel
On Fri Jul 15 12:32:30 2016, mt1...@gmail.com wrote:
> With Rakudo version 2016.06-234-g0189851 built on MoarVM version
> 2016.06-9-g8fc21d5
> implementing Perl 6.c on a Asus laptop running Fedora 23 I see the
> following happen. Running the code below is doing well but when the code
> in the cr
# New Ticket Created by mt1957
# Please include the string: [perl #128628]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128628 >
Hi,
With Rakudo version 2016.06-234-g0189851 built on MoarVM version
2016.06-9-g8fc21d5
imple
Zoffix++ lead to the discovery of a similar bug which can be golfed to:
00:16 < llfourn> m: my $*A = 42; do { start { $*A++ } }; sleep 2; say $*A
00:16 <+camelia> rakudo-moar fbe0a6: OUTPUT«42»
if you put the block outside the start {} you don't get an error but you
don't get the side affects.
> On 26 Dec 2015, at 13:12, Lloyd Fournier (via RT)
> wrote:
>
> # New Ticket Created by Lloyd Fournier
> # Please include the string: [perl #127033]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127033 >
>
>
> perl6
# New Ticket Created by Lloyd Fournier
# Please include the string: [perl #127033]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127033 >
perl6 -e 'sub t { say $*d }; my $*d = 1; await do { start { t() } }'
#!>Dynamic varia
tps://gist.github.com/BenGoldberg1/bc39a9a31eaeb733012a creates
many threads for the task of sorting numbers as they are sent to a channel.
Roughly twice as many threads are created as there are distinct values.
The output should be a list of random numbers, sorted.
Instead, it produces a error mess
any threads for the task of sorting numbers as they are sent to a channel.
Roughly twice as many threads are created as there are distinct values.
The output should be a list of random numbers, sorted.
Instead, it produces a error message; changing the number of element to be
sorted causes
# New Ticket Created by Rob Hoelz
# Please include the string: [perl #125977]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=125977 >
If I do something like this:
for ^1000 {
Thread.start({}).join;
}
MoarVM w
:
M S29-functions.pod
Log Message:
---
Elaborate a bit on exit, END blocks and threads
Howdy,
This is great news! Thanks to Reini and all the developers and GSoC
students that made this possible.
Duke
On Mon, Dec 3, 2012 at 11:24 AM, Reini Urban wrote:
> I've tested and merged the threads branch today with 6b0fab6 and 637a135.
> I've also updated the native_p
I've tested and merged the threads branch today with 6b0fab6 and 637a135.
I've also updated the native_pbc's as I had to bump PBC_COMPAT to 13.0
4.11.0 will not need to bump it again as I plan to merge
rurban/gh870-pmc_class and native_pbc
branches before.
native_pbc will contai
We have a litle blocking situation with our parrot threads.
See https://github.com/parrot/parrot/issues/869 and tadzik's crashing nqp case.
tadzik.nqp:
say("alive");
my $x := 5;
my $a := sub foo() {
say($x);
say(5);
}
my $b := pir::new__PSP('Task', $a);
p
ht be used.
>>
>> For the love of $DEITY, let's please not repeat ithreads!
>
> It's worth remembering that ithreads are far superior to the older
> 5005threads model, where multiple threads ran with an interpreter.
> [Shudder]
>
> It's also worth remember
On Fri, Oct 15, 2010 at 11:04:18AM +0100, Tim Bunce wrote:
> On Thu, Oct 14, 2010 at 11:52:00PM -0400, Benjamin Goldberg wrote:
> >> From: tim.bu...@pobox.com
> >>
> >> So I'd like to use this sub-thread to try to identify when lessons we
> >> can learn from ithreads. My initial tho
On Fri, Oct 15, 2010 at 10:22 AM, B. Estrade wrote:
> Pardon my ignorance, but are continuations the same thing as
> co-routines, or is it more primitive than that?
Continuations are not the same thing as coroutines, although they can
be used to implement coroutines - in fact, continuations can b
e problem.
>
> --
> Mark J. Reed
What prevents perl6 from having both fibers *and* an event loop?
After all, with perl5, you can use Coro and AnyEvent together... they
seem to be a good combo.
Perhaps we don't need threads?
Let's suppose that we provide an easy to us
I would implement threads in the following form
$thread_counter = 0;
$global = "lock";
$thread = new thread( \&thread_sub );
$thread->start();
thread_sub {
lock( $global ) {
print "i'm thread ", ++$thread_counter, "\n";
On Thu, Oct 21, 2010 at 6:04 PM, Darren Duncan wrote:
> Aaron Sherman wrote:
>
>>
> Things that typically precipitate threading in an application:
>>
>> - Blocking IO
>> - Event management (often as a crutch to avoid asynchronous code)
>> - Legitimately parallelizable, intense computing
>>
Aaron Sherman wrote:
On Tue, Oct 12, 2010 at 10:22 AM, Damian Conway wrote:
Perhaps we need to think more Perlishly and reframe the entire question.
Not: "What threading model do we need?", but: "What kinds of non-sequential
programming tasks do we want to make easy...and how would we like to b
On Tue, Oct 12, 2010 at 10:22 AM, Damian Conway wrote:
> Perhaps we need to think more Perlishly and reframe the entire question.
> Not: "What threading model do we need?", but: "What kinds of non-sequential
> programming tasks do we want to make easy...and how would we like to be
> able to spec
I've done quite a lot of concurrent programming over the past 23ish years,
from the implementation of a parallelized version of CLIPS back in the late
80s to many C, Perl, and Python projects involving everything from shared
memory to process pooling to every permutation of hard and soft thread
man
t; the meme might have its roots in that Guy you mention.)
>
> <http://irclog.perlgeek.de/perl6/2010-10-15#i_2914961>
>
> Perl 6 has all the prerequisites for making this happen. It's mostly a
> question of marking things up with some trait or other.
>
> our mul
It's mostly a
question of marking things up with some trait or other.
our multi sub infix:<+>($a, $b) will optimize {
...
}
(User-defined ops can be markes in exactly the same way.)
All that's needed after that is a &reduce sub that's sensitive to such
traits. Oh, and threads.
// Carl
On Oct 12, 2010, at 9:22 AM, Damian Conway wrote:
> Perhaps we need to think more Perlishly and reframe the entire question.
> Not: "What threading model do we need?", but: "What kinds of non-sequential
> programming tasks do we want to make easy...and how would we like to be
> able to specify tho
interpreter, would hold the interpreter's "global" state.
If this is the case, I think it may be helpful to state more precisely
what state you think would need to be cloned or recreated between
"threads" or "processes" and what would not.
Also, it is import
Earlier, Leon Timmermans wrote:
: * Code sharing is actually quite nice. Loading Moose separately in a
: hundred threads is not. This is not trivial though, Perl being so
On Fri, Oct 15, 2010 at 09:57:26AM -0400, Mark J. Reed wrote:
> On Fri, Oct 15, 2010 at 7:42 AM, Leon Timmermans wrote:
> > Continuations and fibers are incredibly useful and should be easy to
> > implement on parrot/rakudo but they aren't really concurrency. They're
> > a solution to a different
On Thu, Oct 14, 2010 at 11:52:00PM -0400, Benjamin Goldberg wrote:
>> From: tim.bu...@pobox.com
>>
>> So I'd like to use this sub-thread to try to identify when lessons we
>> can learn from ithreads. My initial thoughts are:
>>
>> - Don't clone a live interpreter.
>> Sta
> Date: Tue, 12 Oct 2010 23:46:48 +0100
> From: tim.bu...@pobox.com
> To: faw...@gmail.com
> CC: ben-goldb...@hotmail.com; perl6-langu...@perl.org
> Subject: Lessons to learn from ithreads (was: threads?)
>
> On Tue, Oct 12, 2010 at 03:42:00PM +0200, Leon Timmermans wrot
On Fri, Oct 15, 2010 at 01:42:06PM +0200, Leon Timmermans wrote:
> On Wed, Oct 13, 2010 at 1:20 AM, Tim Bunce wrote:
> > I've not used them, but Ruby 1.9 Fibers (continuations) and the
> > EventMachine Reactor pattern seem interesting.
>
> Continuations and fibers are incredibly useful and should
On Fri, Oct 15, 2010 at 7:42 AM, Leon Timmermans wrote:
> Continuations and fibers are incredibly useful and should be easy to
> implement on parrot/rakudo but they aren't really concurrency. They're
> a solution to a different problem.
I would argue that concurrency isn't a problem to solve; it'
On Wed, Oct 13, 2010 at 1:20 AM, Tim Bunce wrote:
> I've not used them, but Ruby 1.9 Fibers (continuations) and the
> EventMachine Reactor pattern seem interesting.
Continuations and fibers are incredibly useful and should be easy to
implement on parrot/rakudo but they aren't really concurrency.
On Wed, Oct 13, 2010 at 1:13 PM, Tim Bunce wrote:
> If you wanted to start a hundred threads in a language that has good
> support for async constructs you're almost certainly using the wrong
> approach. In the world of perl6 I expect threads to be used rarely and
> for spe
> And for which kinds of tasks?
>
> And we also need to stand back a little further and ask: is "threading"
> the right approach at all? Do threads work in *any* language? Are there
> better metaphors?
'Channels are a good model of the external world' - Russ Co
On Tue, Oct 12, 2010 at 02:31:26PM +0200, Carl M?sak wrote:
> Ben (>):
> > If perl6 can statically (at compile time) analyse subroutines and
> > methods and determine if they're reentrant, then it could
> > automatically use the lightest weight threads when it knows
- Don't clone a live interpreter.
> > Start a new thread with a fresh interpreter.
> >
> > - Don't try to share mutable data or data structures.
> > Use message passing and serialization.
>
> Actually, that sounds *exactly* like what I have been trying to
>
and back a little further and ask: is "threading"
> the right approach at all? Do threads work in *any* language? Are there
> better metaphors?
A more general metaphore would be asynchronous tasking, a thread being
a long running "implicit" task. Other issues include memory
ractice? What has worked well? What was painful? What was error-prone?
> > And for which kinds of tasks?
>
> Most languages either implement concurrency in a way that's not very
> useful (CPython, CRuby) or implement it in a way that's slightly
> (Java/C/C++) to totally (
input, in all executions.
?By default? means that deterministic behavior is guaranteed unless the
programmer explicitly requests nondeterminism. This is in contrast to
today?s shared-memory programming models (e.g., threads and locks), which
are inherently nondeterministic and can even have
repeat ithreads!
It's worth remembering that ithreads are far superior to the older
5005threads model, where multiple threads ran with an interpreter.
[Shudder]
It's also worth remembering that real O/S level threads are needed to
work asynchronously with third-party libraries that would bloc
at was error-prone?
> And for which kinds of tasks?
>
> And we also need to stand back a little further and ask: is "threading"
> the right approach at all? Do threads work in *any* language? Are there
> better metaphors?
I've not used them, but Ruby 1.9 Fibers (continuat
t; - Don't try to share mutable data or data structures.
> Use message passing and serialization.
Actually, that sounds *exactly* like what I have been trying to
implementing for perl 5 based on ithreads (threads::lite, it's still
in a fairly early state though). My experience wit
I agree that threads are generelly a difficult issue to cope. What is
worse, there are a lot of Java-developers who tell us, that it is not
difficult for them,
but in the end the software fails on the productive system, for example
because the load is different then on the test system, causing
Damian Conway wrote:
Perhaps we need to think more Perlishly and reframe the entire question.
Not: "What threading model do we need?", but: "What kinds of non-sequential
programming tasks do we want to make easy...and how would we like to be
able to specify those tasks?"
The mindset that I u
licitly lock or explicitly do a
transaction.
> It'd be a shame to not provide a way to both use threads directly or
> to fallback to some implicitly concurrent constructs.
I agree
plement concurrency in a way that's not very
useful (CPython, CRuby) or implement it in a way that's slightly
(Java/C/C++) to totally (perl 5) insane. Erlang is the only language
I've worked with whose threads I really like, but sadly it's rather
weak at a lot of other things.
I
or-based concurrency model[1] might be
a better way to go than the current threads-based mindset. Certainly,
it's often easier to think of actors who talk to each other to get
things done than it is to think of processes (or threads) as things
unto themselves.
[1] http://en.wikipedia.org/wiki/Actor_model
--
Jonathan "Dataweaver" Lang
ror-prone?
> And for which kinds of tasks?
>
> And we also need to stand back a little further and ask: is "threading"
> the right approach at all? Do threads work in *any* language? Are there
> better metaphors?
> [...]
I agree fully with Damian. At YAPC::EU in Pis
Damian, I use threads in C++ a lot in my day to day job. We use an
in-house library which isn't much more than a thread class which you
inherit from and give a Run method to, and a load of locks of various
(sometimes ill-defined) kinds.
Let me say: it's not good. Threads with sema
y.
--- Phil
-Original Message-
From: thoughtstr...@gmail.com [mailto:thoughtstr...@gmail.com] On Behalf Of
Damian Conway
Sent: October 12, 2010 10:23 AM
To: perl6-langu...@perl.org
Subject: Re: threads?
Leon Timmermans wrote:
> For the love of $DEITY, let's please n
at has worked
in practice? What has worked well? What was painful? What was error-prone?
And for which kinds of tasks?
And we also need to stand back a little further and ask: is "threading"
the right approach at all? Do threads work in *any* language? Are there
better metaphors?
Perhap
On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg wrote:
> If thread-unsafe subroutines are called, then something like ithreads
> might be used.
For the love of $DEITY, let's please not repeat ithreads!
Ben (>):
> If perl6 can statically (at compile time) analyse subroutines and
> methods and determine if they're reentrant, then it could
> automatically use the lightest weight threads when it knows that the
> entry sub won't have side effects or alter global data.
I
Has there been any decision yet over what model(s) of threads perl6
will support?
Will they be POSIX-like? ithread-like? green-thread-like?
It is my hope that more than one model will be supported... something
that would allow the most lightweight threads possible to be used
where possible, and
o Vim for editing/wrapping.)
Let's give this another try with the original content:
For newbies, here's the "About" page for Stackoverflow.com:
http://stackoverflow.com/about
Page showing questions that are tagged "perl6"
http://stackoverflow.com/questions/tagge
* Larry Wall <[EMAIL PROTECTED]> [2008-10-07 18:10]:
> Anyway, my mailer is not smart enough to intuit that the next
> line should be glued to the previous, and arguably if it were
> smart enough, it would be making unwarranted guesses anyway,
> since there's really no way of knowing for sure, apar
By the by, I don't know what you're using to send mail, but it's a
bit difficult to extract URIs from your message when most of them are
broken by autowrapping. This will be a more frequent problem as long
as the average length of URIs in the world is growing, so it's probably
worth dealing with.
Thought some of you might find this interesting
For newbies, here's the "About" page for Stackoverflow.com:
http://stackoverflow.com/about
Page showing questions that are tagged "perl6"
http://stackoverflow.com/questions/tagged/perl6
Perl 6
Conrad (>):
> http://stackoverflow.com/questions/170268/what-features-of-perl6-are-you-the-most-excited-about
>
> (Of course I added "NOVEMBER" to the list of answers.)
Heartfelt thanks for that. That is, indeed, a creative way to
interpret the term "feature of Perl 6". :)
You also writ
1 - 100 of 550 matches
Mail list logo
