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_pbc's as I had to bum
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";
}
}
It's a mixture of ithreads and the C# t
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
On Sun, Oct 17, 2010 at 01:18:09AM +0200, Carl Mäsak wrote:
> Damian (>>), Matt (>):
> >> 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 ho
Damian (>>), Matt (>):
>> 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?"
>
> I watched
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
On 2010-Oct-12, at 10:22, Damian Conway wrote:
> What we really need is some anecdotal evidence from folks who are actually
> using threading in real-world situations (in *any* languages). What has worked
> in practice? What has worked well? What was painful? What was error-prone?
> And for which
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 that the
> > entry sub won't hav
On Tue, Oct 12, 2010 at 07:22:33AM -0700, Damian Conway wrote:
> Leon Timmermans wrote:
>
> > For the love of $DEITY, let's please not repeat ithreads!
>
> $AMEN!
>
> Backwards compatibility is not the major design criterion for Perl 6,
> so there's no need to recapitulate our own phylogeny here
On Tue, Oct 12, 2010 at 10:43:44PM +0200, Leon Timmermans wrote:
> On Tue, Oct 12, 2010 at 4:22 PM, Damian Conway wrote:
> > The problem is: while most people can agree on what have proved to be
> > unsatisfactory threading models, not many people can seem to agree on
> > what would constititute a
I haven't enough smarts to see if this is at all what you're looking for
but is used some of the same terms:
http://dpj.cs.uiuc.edu/DPJ/Home.html?cid=nl_ddjupdate_2010-10-12_html
Welcome to the home page for the Deterministic Parallel Java (DPJ) project
at the University of Illinois at Urbana-C
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 dif
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
On Tue, Oct 12, 2010 at 10:28 PM, B. Estrade wrote:
>> I agree. I would prefer implicit over explicit concurrency wherever possible.
>
> I know you're speaking about the Perl interface to concurrency, but
> you seem to contradict yourself because message passing is explicit
> whereas shared memory
On Tue, Oct 12, 2010 at 4:22 PM, Damian Conway wrote:
> The problem is: while most people can agree on what have proved to be
> unsatisfactory threading models, not many people can seem to agree on
> what would constititute a satisfactory threading model (or, possibly, models).
>
> What we really
When Larry decided that Perl 6 would incorporate concepts from
prototype-based objects, he did so at least in part because it's more
intuitive for people to work with, e.g., "a cow" than it is to try to
work with "the concept of a cow" as a thing unto itself. In a similar
way, I think that Perl's
On Tue, Oct 12, 2010 at 07:22:33AM -0700, Damian Conway wrote:
> What we really need is some anecdotal evidence from folks who are actually
> using threading in real-world situations (in *any* languages). What has worked
> in practice? What has worked well? What was painful? What was error-prone?
>
. Channels are first-class in the language and leverage simple
> "goroutine" semantics to invoke concurrency.
>
>
> --- Phil
>
>
>
> -Original Message-
> From: thoughtstr...@gmail.com [mailto:thoughtstr...@gmail.com] On Behalf Of
> Damian Conway
> Sent:
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
Leon Timmermans wrote:
> For the love of $DEITY, let's please not repeat ithreads!
$AMEN!
Backwards compatibility is not the major design criterion for Perl 6,
so there's no need to recapitulate our own phylogeny here.
The problem is: while most people can agree on what have proved to be
unsati
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'm often at the receiving end o
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
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
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.
>
> [ ... ]
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
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 thr
"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. Th
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
> [ 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
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> Yes, there has to be a separate thread to get signals, and each thread
> needs its own event queue, but why does the process have a global
> event_queue? I suppose there are generic events that could be handled
> just by the next thread to call check_even
> >> 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 in the POSIX specific p
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
>> > * COND_WAIT takes a mutex because that's how pthreads works, but Win32
>> > condition variables (called "events") are kernel obj
On Mon, 15 Nov 2004 12:57:00 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> > * COND_WAIT takes a mutex because that's how pthreads works, but Win32
> > condition variables (called "events") are kernel objects that do not
> > require any other object
At 12:57 PM +0100 11/15/04, Leopold Toetsch wrote:
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
I was just browsing the Parrot source, and noticed that the threading
implementation is a bit Unix/pthread-centric. For example:
* COND_WAIT takes a mutex because that's how pthreads works, but Win32
co
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> I was just browsing the Parrot source, and noticed that the threading
> implementation is a bit Unix/pthread-centric. For example:
> * COND_WAIT takes a mutex because that's how pthreads works, but Win32
> condition variables (called "events") are kernel
--- 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
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
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
[ Cygwin thread tests don't print all ]
Does this patch help? It creates shared IO resources. But its of course
not final: there are no precautions against one thread changing the PIO
of another thread or such, no locks yet, nothing.
leo
--- parrot/src/
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
--- 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
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/
--- 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
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
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
--- 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 say
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 ..
--- 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 go
At 1:27 AM -0500 1/30/04, Gordon Henriksen wrote:
On Thursday, January 29, 2004, at 11:55 , Melvin Smith wrote:
At 11:45 PM 1/28/2004 -0500, Gordon Henriksen wrote:
On Wednesday, January 28, 2004, at 12:53 , Melvin Smith wrote:
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
Java Collections ar
On Thursday, January 29, 2004, at 11:55 , Melvin Smith wrote:
At 11:45 PM 1/28/2004 -0500, Gordon Henriksen wrote:
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
structur
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
At 11:45 PM 1/28/2004 -0500, Gordon Henriksen wrote:
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;
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 th
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
Pardon me, I am trudging through all this thread backlog and
have been trying not to post to add to the bandwidth.
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
An existence proof:
Java Collections are a standard Java library of common data structures
such as arrays and hashes. Collections are
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
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 m
On Fri, Jan 23, 2004 at 10:07:25AM -0500, Dan Sugalski wrote:
> A single global lock, like python and ruby use, kill any hope of
> SMP-ability.
Assume, for the sake of argument, that locking almost every PMC
every time a thread touches it causes Parrot to run four times
slower. Assume also that
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 bi
At 5:58 PM -0500 1/22/04, Josh Wilmes wrote:
I'm also concerned by those timings that leo posted.
0.0001 vs 0.0005 ms on a set- that magnitude of locking overhead
seems pretty crazy to me.
It looks about right. Don't forget, part of what you're seeing isn't
that locking mutexes is slow, it's that
At 5:24 PM -0500 1/22/04, Deven T. Corzine wrote:
Dan Sugalski wrote:
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 th
I'm also concerned by those timings that leo posted.
0.0001 vs 0.0005 ms on a set- that magnitude of locking overhead
seems pretty crazy to me.
It seemed like a few people have said that the JVM style of locking
can reduce this, so it seems to me that it merits some serious
consideration, even
Dan Sugalski wrote:
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
At 23:10 -0500 1/5/04, Gordon Henriksen wrote:
Data corruption unacceptable? I disagree.
I get the feeling people just aren't reading what's been written, or
aren't keeping it all straight.
*User* and *program* data integrity is not our problem -- not only
are we not guaranteeing that, I'd be fi
At 23:10 -0500 1/5/04, Gordon Henriksen wrote:
Data corruption unacceptable? I disagree. It depends on the contract
put forward by the language in question. Notably, Perl makes no such
guarantees thus far, being as how it doesn't (any longer) run in a
traditional threaded model. Successfully thr
Gordon Henriksen wrote:
> Dan Sugalski wrote:
> >
> > An interpreter *must* lock any shared data structure,
> > including PMCs, when accessing them. Otherwise they may
> > be in an inconsistent state when being accessed, which will
> > lead to data corruption or process crashing, which is
> > una
On Sunday, January 4, 2004, at 01:43 , Dan Sugalski wrote:
At 11:59 PM -0500 1/3/04, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
Com
On Sunday, January 4, 2004, at 03:17 , Jeff Clites wrote:
On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
C
At 4:03 PM -0800 1/4/04, Damien Neil wrote:
It's my understanding that Parrot has chosen to take the path of using
many mutable data structures at the VM level; unfortunately, this is
pretty much incompatible with a fast or elegant threading model.
Yep, generally true. The choice was made on purpos
At 2:43 AM + 1/5/04, Nigel Sandever wrote:
05/01/04 01:22:32, Sam Vilain <[EMAIL PROTECTED]> wrote:
[STUFF] :)
In another post you mentions intel hyperthreading.
Essentially, duplicate sets of registers within a single CPU.
Do these need to apply lock on every machine level entity that
they a
05/01/04 04:51:20, Sam Vilain <[EMAIL PROTECTED]> wrote:
>On Mon, 05 Jan 2004 15:43, Nigel Sandever wrote;
>
> > I accept that it may not be possible on all platforms, and it may
> > be too expensive on some others. It may even be undesirable in the
> > context of Parrot, but I have seen no ar
05/01/04 04:34:15, Luke Palmer <[EMAIL PROTECTED]> wrote:
LP> I think you're saying that each thread gets its own register set and
LP> register stacks (the call chain is somewhat hidden within the register
LP> stacks). Dan has been saying we'll do this all along.
.
That has been my interpret
On Mon, 05 Jan 2004 15:43, Nigel Sandever wrote;
> I accept that it may not be possible on all platforms, and it may
> be too expensive on some others. It may even be undesirable in the
> context of Parrot, but I have seen no argument that goes to
> invalidate the underlying premise.
I th
Nigel Sandever writes:
> Whilst the state of higher level objects, that the machine level
> objects are a part of, may have their state corrupted by two
> threads modifying things concurrently. The state of the threads
> (registers sets+stack) themselves cannot be corrupted.
I'm going to ask fo
05/01/04 01:22:32, Sam Vilain <[EMAIL PROTECTED]> wrote:
[STUFF] :)
In another post you mentions intel hyperthreading.
Essentially, duplicate sets of registers within a single CPU.
Do these need to apply lock on every machine level entity that
they access?
No.
Why not?
Because they can only
On Mon, 05 Jan 2004 12:58, Nigel Sandever wrote;
> Everything else, were my attempts at solving the requirements of
> synchronisation that this would require, whilst minimising the
> cost of that synchronisation, by avoiding the need for a mutex on
> every shared entity, and the costs of a
On Sun, Jan 04, 2004 at 12:17:33PM -0800, Jeff Clites wrote:
> What are these standard techniques? The JVM spec does seem to guarantee
> that even in the absence of proper locking by user code, things won't
> go completely haywire, but I can't figure out how this is possible
> without actual loc
On Sun, 4 Jan 2004 15:47:35 -0500, [EMAIL PROTECTED] (Dan Sugalski) wrote:
> *) INTERPRETER - those bits of the Parrot_Interp structure that are
> absolutely required to be thread-specific. This includes the current
> register sets and stack pointers, as well as security context
> information.
At 9:27 AM +1300 1/5/04, Sam Vilain wrote:
On Sat, 03 Jan 2004 20:51, Luke Palmer wrote;
> Parrot is platform-independent, but that doesn't mean we can't
> take advantage of platform-specific instructions to make it faster
> on certain machines. Indeed, this is precisely what JIT is.
> B
At 3:17 PM -0500 1/4/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> And don't forget the libraries that are picky about which thread calls
DS> into them -- there are some that require that the thread that created
DS> the handle for the library be the threa
On Sat, 03 Jan 2004 20:51, Luke Palmer wrote;
> Parrot is platform-independent, but that doesn't mean we can't
> take advantage of platform-specific instructions to make it faster
> on certain machines. Indeed, this is precisely what JIT is.
> But a lock on every PMC is still pretty hea
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> And don't forget the libraries that are picky about which thread calls
DS> into them -- there are some that require that the thread that created
DS> the handle for the library be the thread that calls into the library
DS> with that
On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise. Shouldn't
At 12:05 PM -0800 1/4/04, Jeff Clites wrote:
On Jan 4, 2004, at 5:47 AM, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
When you use an external library in Perl, such as e.g. libxml, you
have Perl data-structures and libxml data-structures. The Perl
data-structures contain
On Jan 4, 2004, at 5:47 AM, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
When you use an external library in Perl, such as e.g. libxml, you
have Perl data-structures and libxml data-structures. The Perl
data-structures contain pointers to the libxml data-structures.
In
At 11:59 PM -0500 1/3/04, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise. Shouldn't ev
At 14:47 +0100 1/4/04, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> When you use an external library in Perl, such as e.g. libxml, you
have Perl data-structures and libxml data-structures. The Perl
> data-structures contain pointers to the libxml data-structures.
> I
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> When you use an external library in Perl, such as e.g. libxml, you
> have Perl data-structures and libxml data-structures. The Perl
> data-structures contain pointers to the libxml data-structures.
> In comes the starting of an ithread and Perl cl
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed automatically
by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise. Shouldn't even be
pursued.
Atomic guarantees on collections
At 00:49 +0100 1/4/04, Leopold Toetsch wrote:
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> Indeed. But as soon as there is something special such as a
datastructure external to Perl between threads (which happens
automatically "shared" automatically, because Perl doesn't know about
> the d
On Jan 3, 2004, at 2:59 PM, Leopold Toetsch wrote:
Nigel Sandever <[EMAIL PROTECTED]> wrote:
Only duplicating shared data on demand (COW) may work well on systems
that support COW in the kernel.
No, we are dealing with VM objects and structures here - no kernel is
involved for COWed copies of e.g.
Nigel Sandever <[EMAIL PROTECTED]> wrote:
> On Sat, 3 Jan 2004 21:00:31 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
>> Yep. So if a single interpreter (which is almost a thread state) should
>> run two threads, you have to allocate and swap all.
> When a kernel level thead is spawned, no dup
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> Indeed. But as soon as there is something special such as a
> datastructure external to Perl between threads (which happens
> automatically "shared" automatically, because Perl doesn't know about
> the datastructure,
Why is it shared automatically
Uri Guttman <[EMAIL PROTECTED]> wrote:
> ... this again brings up how we lock so
> that GC/alloc will work properly with threads. do we lock a thread pool
> but not the thread when we access a shared thingy?
This is the major issue, how to continue. Where are shared objects
living (alloc) and wher
Uri Guttman <[EMAIL PROTECTED]> wrote:
> ok, i missed the 'if' there. :)
> that could be workable and might be faster. it does mean that locks are
> two step as well, user space test/set and fallback to kernel lock.
Yep, that is, what the OS provides. I really don't like to reinvent
wheels here
At 21:11 + 1/3/04, Dave Mitchell wrote:
On Sat, Jan 03, 2004 at 08:05:13PM +0100, Elizabeth Mattijsen wrote:
> Actually, you can bless a reference to a shared variable, but you
can't share a blessed object (the sharing will let you lose the
content of the object). I think shared compound da
> "JC" == Jeff Clites <[EMAIL PROTECTED]> writes:
JC> On Jan 3, 2004, at 12:26 PM, Uri Guttman wrote:
>> that could be workable and might be faster. it does mean that locks
>> are two step as well, user space test/set and fallback to kernel
>> lock. we can do what nigel said and wrap
1 - 100 of 196 matches
Mail list logo
