You cannot go further without either breaking existing code.
You *can* fix the code in a fork. This gives people the of switching to the
fork when *they* want to. Or don’t switch.
Seems to me forking is the only way forward.
Just my 2c worth, having been exposed to these shenanigans of point
How time flies when you're having some days off...
On Mar 15, 2012, at 1:35 PM, Tim Bunce wrote:
> On Wed, Mar 14, 2012 at 01:35:21PM +0100, Elizabeth Mattijsen wrote:
>> Maybe some background first:
>>
>> I'm working on code that does queries on large tables.
On Mar 14, 2012, at 1:35 PM, Elizabeth Mattijsen wrote:
> Maybe some background first:
>
> I'm working on code that does queries on large tables. To be able to support
> the growth of these tables, we need to shard the tables to multiple database
> servers. One way to shar
$old->swap_inner_handle($new); # wherever $new comes from, not important
here
}
Then it would be possible to completely hide the sharding of the databases from
our code. Which would make life a lot easier on a lot of people now and in the
future.
So, does that make sense? Have I missed
At 15:15 -0800 2/16/04, Dean Arnold wrote:
Attempt to free unreferenced scalar: SV 0x280bac00 at
C:/Perl/site/lib/DBI.pm line 633.
DBI::__ANON__[C:/Perl/site/lib/DBI.pm:646]('undef','undef') called at
Perl ithreads used to have a lot of issues with freeing unreferenced
scalars. They're s
At 00:29 + 1/27/04, Tim Bunce wrote:
On Sun, Jan 25, 2004 at 11:14:45PM +, Tim Bunce wrote:
> Here's a draft of an announcement about the Parrot DBDI project.
Stunned silence?
Mydoomed silence, maybe?
I will mostly be lurking here, though... ;-)
Liz
At 23:16 + 1/28/04, Tim Bunce wrote:
On Wed, Jan 28, 2004 at 10:43:57PM +0100, Elizabeth Mattijsen wrote:
At 00:29 + 1/27/04, Tim Bunce wrote:
>On Sun, Jan 25, 2004 at 11:14:45PM +, Tim Bunce wrote:
> > Here's a draft of an announcement about the Parrot DBDI projec
At 12:20 PM 10/21/02 -0400, Harvey Cary wrote:
I have to agree with the question of how you plan on taking over DBD::Pg
if your no prel programmer. That has got to be the craziest thing I ever
heard. I hope that someone else takes it over, I will voluntier, as I am
a perl programmer that uses DGD:
At 05:00 PM 8/12/02 +0100, Tim Bunce wrote:
> > I thought the seperate thread idea might be important to DBI developers
> who
> > are porting to threads...
>You could perhaps post pointers to potentially interesting threads.
>Or post an initial message and set the Reply-To header to p5p.
Since I
At 03:48 PM 8/12/02 +0100, Tim Bunce wrote:
>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
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
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
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
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
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
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
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
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
As promised on P5P, this is the first version of my proof of concept
implementation for shared variables using a seperate thread.
Have fun and let me know if it helps you.
Liz
===
The uploaded file
Thread-Tie-0.01.tar.gz
At 09:28 PM 7/23/02 +0100, Tim Bunce wrote:
>Each thread/interpreter needs to make it's own connection to the database.
>Handles cannot be shared between threads (either by passing or being cloned).
This is the same type of problem that Thread::Queue::Any solves by
serializing data between threa
21 matches
Mail list logo
