in reply to Re^4: mutiple threading
in thread mutiple threading

Hi,

I found the following in CPAN

Making your module threadsafe

Since 5.6.0, Perl has had support for a new type of threads called interpreter threads (ithreads). These threads can be used explicitly and implicitly.

Ithreads work by cloning the data tree so that no data is shared between different threads. These threads can be used by using the threads module or by doing fork() on win32 (fake fork() support). When a thread is cloned all Perl data is cloned, however non-Perl data cannot be cloned automatically. Perl after 5.7.2 has support for the CLONE special subroutine. In CLONE you can do whatever you need to do, like for example handle the cloning of non-Perl data, if necessary. CLONE will be called once as a class method for every package that has it defined (or inherits it). It will be called in the context of the new thread, so all modifications are made in the new area. Currently CLONE is called with no parameters other than the invocant package name, but code should not assume that this will remain unchanged, as it is likely that in future extra parameters will be passed in to give more information about the state of cloning.

If you want to CLONE all objects you will need to keep track of them per package. This is simply done using a hash and Scalar::Util::weaken().

Perl after 5.8.7 has support for the CLONE_SKIP special subroutine. Like CLONE, CLONE_SKIP is called once per package; however, it is called just before cloning starts, and in the context of the parent thread. If it returns a true value, then no objects of that class will be cloned; or rather, they will be copied as unblessed, undef values. This provides a simple mechanism for making a module threadsafe; just add sub CLONE_SKIP { 1 } at the top of the class, and DESTROY() will be now only be called once per object. Of course, if the child thread needs to make use of the objects, then a more sophisticated approach is needed.

Like CLONE, CLONE_SKIP is currently called with no parameters other than the invocant package name, although that may change. Similarly, to allow for future expansion, the return value should be a single 0 or 1 value.

So do you think I can make my DBI thread safe ? please let me know your thoughts. I am asking about threadsafty of DBI and not with respect to above program.

Thanks in advance.

--VC


There are three sides to any argument.....
your side, my side and the right side.

Replies are listed 'Best First'.
Re^6: mutiple threading
by BrowserUk (Patriarch) on Aug 24, 2007 at 05:31 UTC

    I can only direct you to the paragraph labelled "Thread Safety" in the pod for DBI. From which I'll just quote a selective highlight.

    But BEWARE, .... You have been warned.

    The passage you quoted is aimed at the authors of modules, not users. Unless you are the author of DBI, and the DB-specific drivers that run on top of it, and you are very knowledgable about the internals of the vendor-supplied DB interface drivers, you should probably not be trying to "make my DBI thread safe". Accept the limitation and consider other ways of tackling your problem.

    The first thing to consider is: why do you want to access the database from multiple threads in the first place? If you can describe the application that you envisage using this for, then it may be demonstrable that there would be no benefit to having multiple threads accessing the DB. It may be better to have a single thread that fetches the data and then mutiple threads to process it.

    Without specific scenarios, it's not at all clear whether there would be any benefit to doing this.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom