01-05-09 16.32, skrev Jarkko Hietaniemi p� [EMAIL PROTECTED] f�ljande:
> On Wed, May 09, 2001 at 04:04:22PM +0200, Artur Bergman wrote:
>> 01-05-09 15.58, skrev Chip Cuntz p� [EMAIL PROTECTED] f�ljande:
>>
>>> I might be able to help. Since I am so new to the list what kind of testing
>>> of local time needs to be done?
>>>
>>> -----Original Message-----
>>> From: Artur Bergman [mailto:[EMAIL PROTECTED]]
>>> Sent: Wednesday, May 09, 2001 5:35 AM
>>> To: [EMAIL PROTECTED]
>>> Subject: Reports and questions.
>>>
>>> It would be nice if somone could help writing test cases for more functions
>>> to map the problem area.
>>>
>>>
>>
>> Basicly the problem is if you call some functions at the same time you get
>> different results because they interfer wich each other.
>>
>> I will write a paper and an example on how the localtime test works and post
>> it with the new release.
>
> Uhhh....Sarathy will accuse me of FUDing again :-) but you can't
> really test for threadsafety of X. Not in any useful manner, anyway.
>
> (0) You must run the test in a true multi-CPU box. Otherwise you
> will not get race for the same state.
>
> (1) You cannot prove threadsafety. You may run the X test for
> an hour, a day, a week, and still not see data corruption.
> In simple cases like localtime the corruption may of course
> hit much earlier.
>
> (2) You can prove threadUNsafety. As soon as you see data corruption
> you know your X is-- but there's no saying how soon that will
> happen.
>
>> Artur
Yes Jarkko, I am aware of point 1,2,3.
However I am faced with the following facts.
Some perl functions are not threadsafe on some platforms
We have no idea how widespread this is
Fixing it is usually enough with slapping a mutex around it,
Another way of fixing it is *_r and friends
The last option includes alot of work for other people, work I don't want to
demand somone to do nor can I argue that it is worth the effort to do so,
(not yet atleast). In effect the entire iThread thing is still an
experiment, and I would like a rough map of what breaks where and if we can
fix it from perl.
When it comes to true multi cpu box I only have one dual machine I can play
with (doesn't matter if I crash it), and that is a linux machine. But yes I
am very aware of the dangers with multithreading on multi cpu machines.
I just went by Amazon and bought everything that I don't have wrt threads
and also the GlibC book, I also started reading up a bit on the glibc
sources (even if I have mainly stumbled in the dark) to start to understand
more about the threadness of the underlaying C library. However my
experience with other c libraries are limited and I am not going to go there
yet.
Artur
