|
|
|
| Think about Loose Coupling | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
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) In reply to Re: Re: Perl should start to specify which function and module are thread-safe
by pg
|
|