Re: Re: Perl should start to specify which function and module are thread-safe

[pg]

I understand what you said and fully agree with you. Your comment definitely made this thread more complete.

However the situation here is a little bit more complex than what you just stated.

From my application point of view, locking is not a problem. As you can see, I didn't use any lock at all, because each child thread will only access that array element belongs to it, so lock is not required from my point of view, or to be precise, my application's point of view.

Now as for the internals used by Tie::File. I don't care, and I SHOULD NOT care. Although I read the code of that module before, but that is not required for using the module, thus there is no way to require the user to help lock Tie::File internals, as he/she most likely has no appreciation of what is going on in that module.

If my logic requires some lock, the only thing I would and I am supposed to lock is @array, not any Tie::File internals.

As for those Tie::File internals, if the author wants to make his package thread-safe, go do something, redesign it, apply lock whenever it is required ...

Yes, to make a OO module thread-safe is a much bigger challenge than to make a usual function thread-safe, and this is my experience with c++ classes and pthread. This is for sure, and this most likely would require fundamental changes to Perl OO, (and I am thinking probably even the way perl variables are scoped, especially the main:: scope)

[integral]

My point of view is that it should be the job of the module writer to guess every possible situation of when a object. And this applies fine was a simple object like the Employee or Person often used in OO tuts. But it begins to break down when you get objects which could benefit from higher-grain locks. My approach would not to include locking in the core modules since this increases overhead in the large number of applications with threads, but to instead use an adaptor or subclass to wrap locks around each record and to manage them.

You make a good point that by encapsulation you shouldn't need to know about locking, but surely the core algorithms for mapping a file to an array don't need to know about thread locking? This would be best served by adding another layer on top of the existing class.

--
integral, resident of freenode's #perl