Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
>At 04:59 PM 8/12/02 +0100, Nick Ing-Simmons wrote:
>> >I'm not sure I'm following you here... Could you elaborate?
>>tie @tied_array; # 1 elements say
>>
>>foreach my $value (@tied_array) # 1 extra SVs tied to elements
>> {
>> print $v
At 04:59 PM 8/12/02 +0100, Nick Ing-Simmons wrote:
> >I'm not sure I'm following you here... Could you elaborate?
>tie @tied_array; # 1 elements say
>
>foreach my $value (@tied_array) # 1 extra SVs tied to elements
> {
> print $value;
> } # all freed here
>
>foreach my $i (0..$#tie
Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
>At 02:59 PM 8/12/02 +0200, Arthur Bergman wrote:
>>>You mean an OS that yields()? The thing is that using shared variables
>>>_doesn't_ eat away at CPU as my approach does. Maybe that is caused by
>>>the client/server swap you (or Arthur?) were
Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
>At 10:45 AM 8/12/02 +0100, Nick Ing-Simmons wrote:
>> >Maybe it is from a CPU point of view, but it definitely isn't from a memory
>> >point of view. Because now in an array each element will need to be tied
>> >to the shared magic.
>>It isn't quit
On Fri, Aug 09, 2002 at 10:12:35PM +0200, Elizabeth Mattijsen wrote:
> As promised on P5P, this is the first version of my proof of concept
> implementation for shared variables using a seperate thread.
Thanks for all the info in the thread, but it's probably best to drop
[EMAIL PROTECTED] from
On måndag, augusti 12, 2002, at 03:22 , Elizabeth Mattijsen wrote:
>
> H... is that something you want me to try out? Or do you want to
> have this be part of the documentation?
>
>
> My first question would be: why would I need to do a sleep 0? Why
> can't threads->yield do that for me
At 02:59 PM 8/12/02 +0200, Arthur Bergman wrote:
>>You mean an OS that yields()? The thing is that using shared variables
>>_doesn't_ eat away at CPU as my approach does. Maybe that is caused by
>>the client/server swap you (or Arthur?) were describing...
>If yield() doesn't yield one might tr
On söndag, augusti 11, 2002, at 04:40 , Jason E. Stewart wrote:
>
> I believe that is what Arthur was saying, the message is an error, it
> should be saying '2 threads were running', at least that is what I
> read.
>
> jas.
>
>
Correct.
Arthur
On måndag, augusti 12, 2002, at 11:45 , Nick Ing-Simmons wrote:
> Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
>> At 12:12 PM 8/11/02 +0100, Nick Ing-Simmons wrote:
The Thread::Tie module is a proof-of-concept implementation of
another
approach to shared variables. Instead of
On måndag, augusti 12, 2002, at 12:16 , Elizabeth Mattijsen wrote:
>>
>
> You mean an OS that yields()? The thing is that using shared variables
> _doesn't_ eat away at CPU as my approach does. Maybe that is caused by
> the client/server swap you (or Arthur?) were describing...
>
>
If yield
At 10:45 AM 8/12/02 +0100, Nick Ing-Simmons wrote:
> >Maybe it is from a CPU point of view, but it definitely isn't from a memory
> >point of view. Because now in an array each element will need to be tied
> >to the shared magic.
>It isn't quite that bad. When you do a FETCH the returned value ge
Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
>At 12:12 PM 8/11/02 +0100, Nick Ing-Simmons wrote:
>> >The Thread::Tie module is a proof-of-concept implementation of another
>> >approach to shared variables. Instead of having shared variables exist
>> >in all the threads from which they are acce
"Elizabeth Mattijsen" <[EMAIL PROTECTED]> writes:
> At 02:53 PM 8/11/02 +0200, Arthur Bergman wrote:
> >> Aha! So maybe there the "2 other threads were running" message is
> >> coming from, when you only started one other thread. Does this
> >> shadowy thread run always, even if you don't have
At 02:53 PM 8/11/02 +0200, Arthur Bergman wrote:
>>Aha! So maybe there the "2 other threads were running" message is coming
>>from, when you only started one other thread. Does this shadowy thread
>>run always, even if you don't have threads::shared ?
>No, the is just a missmg, 2 threads were
On söndag, augusti 11, 2002, at 02:02 , Elizabeth Mattijsen wrote:
>
> Aha! So maybe there the "2 other threads were running" message is
> coming from, when you only started one other thread. Does this shadowy
> thread run always, even if you don't have threads::shared ?
>
No, the is just a
At 12:12 PM 8/11/02 +0100, Nick Ing-Simmons wrote:
> >The Thread::Tie module is a proof-of-concept implementation of another
> >approach to shared variables. Instead of having shared variables exist
> >in all the threads from which they are accessible, shared variable exist
> >as "normal", unshar
Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
>At 12:47 PM 8/10/02 +0200, Arthur Bergman wrote:
>>>Ah.. ok... I didn't know that.
>>>But at least the value will only be copied to the thread that actually
>>>requests it, so that is a saving I would think?
>>That is how it works right now, exce
Elizabeth Mattijsen <[EMAIL PROTECTED]> writes:
>As promised on P5P, this is the first version of my proof of concept
>implementation for shared variables using a seperate thread.
>
>
>The Thread::Tie module is a proof-of-concept implementation of another
>approach to shared variables. Instead o
At 11:37 PM 8/10/02 +0200, Arthur Bergman wrote:
>>Simple Matter Of Perseverance?
>Simple Matter of Programming
I think my explanation of the acronym is more appropriate in this case... ;-(
Liz
On lördag, augusti 10, 2002, at 11:35 , Elizabeth Mattijsen wrote:
>
> Simple Matter Of Perseverance?
>
>
> Liz
>
Simple Matter of Programming
Arthur
At 11:29 PM 8/10/02 +0200, Arthur Bergman wrote:
>>Hmmm... thinking some more about this. Why _is_ the FETCHed value of a
>>tied variable saved locally? How would any internal (XS) module know
>>whether it would be ok to use the saved value or to do a FETCH again?
>>
>>Would it not make even m
On lördag, augusti 10, 2002, at 04:58 , Elizabeth Mattijsen wrote:
>
> Hmmm... thinking some more about this. Why _is_ the FETCHed value of a
> tied variable saved locally? How would any internal (XS) module know
> whether it would be ok to use the saved value or to do a FETCH again?
>
> Wou
At 12:47 PM 8/10/02 +0200, Arthur Bergman wrote:
>>Ah.. ok... I didn't know that.
>>But at least the value will only be copied to the thread that actually
>>requests it, so that is a saving I would think?
>That is how it works right now, except that it is cloned aswell, I have a
>patch that wi
At 12:47 PM 8/10/02 +0200, Arthur Bergman wrote:
>>But at least the value will only be copied to the thread that actually
>>requests it, so that is a saving I would think?
>That is how it works right now, except that it is cloned aswell, I have a
>patch that will defer the cloning of shared valu
On lördag, augusti 10, 2002, at 10:57 , Elizabeth Mattijsen wrote:
>
> Ah.. ok... I didn't know that.
>
> But at least the value will only be copied to the thread that actually
> requests it, so that is a saving I would think?
>
>
That is how it works right now, except that it is cloned aswe
At 12:23 AM 8/10/02 +0200, Arthur Bergman wrote:
>>Shared variables in this approach are truly shared. The value of a variable
>>only exists once in memory. This implementation also circumvents the memory
>>leak that currently (threads::shared version 0.90) plagues any shared array
>>or shared h
On fredag, augusti 9, 2002, at 10:12 , Elizabeth Mattijsen wrote:
>
> Shared variables in this approach are truly shared. The value of a
> variable
> only exists once in memory. This implementation also circumvents the
> memory
> leak that currently (threads::shared version 0.90) plagues any
27 matches
Mail list logo
