Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>>>>> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
>JH> Multithreaded programming is hard and for a given program the only
>JH> person truly knowing how to keep the data consistent and threads not
>JH> strangling each other is the programmer. Perl shouldn't try to be too
>JH> helpful and get in the way. Just give user the bare minimum, the
>JH> basic synchronization primitives, and plenty of advice.
>
>The problem I have with this plan, is reconciling the fact that a
>database update does all of this and more. And how to do it is a known
>problem, its been developed over and over again.
Yes - by the PROGRAMMER that does the database access code - that is far higher
level than typical perl code.
If all your data lives in database and you are prepared to lock database
while you get/set them.
Sure we can apply that logic to making statememts coherent in perl:
while (1)
{
lock PERL_LOCK;
do_state_ment
unlock PERL_LOCK;
}
So ONLY 1 thread is ever _in_ perl at a time - easy!
But now _by constraint_ a threaded perl program can NEVER be a performance
win.
The reason this isn't a pain for databases is they have other things
to do while they wait ...
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
