Hi Kristis, I do remember making the change a little while ago. My knowledge of Perl is not extensive, so when I was working on the threaded bit I was coding as if Perl threads where like C++ threads (which they are not - you kindly forwarded me an article at the time). I did do a few changes that stopped any variables that had "changable" data being global. And that is indeed why the get_new_bugtracker function is still there. I hope that this helps. Rob
________________________________ From: Kristis Makris [mailto:[EMAIL PROTECTED] Sent: Sat 21/04/2007 01:46 To: Day, Tony Cc: [email protected]; Robert Hudson Subject: RE: [scmbug-users] Bugzilla Not Being Updated Aha! On Fri, 2007-04-20 at 15:33 -0600, Day, Tony wrote: > Hmm, okay. Well given that my test returned blank values I guess that > confirms your suspicions, right? Any ideas as to why? I once wondered if the threaded implementation might cause that. If these values were created only once during daemon startup by the main thread, and "somehow" these global values were not shared/copied to the new threads. Given that the threaded implementation worked for me under Linux, for me under Windows, and for Thorsten under Windows, I assumed that was never the case. I started thinking about this possibility when Robert sent a patch for TestDirector where he "Moved $request from being a global to a local variable (So multiple requests can be handled at the same time)" http://bugzilla.mkgnu.net/show_bug.cgi?id=264#c13 Robert, can you remember if this $request change was really necessary ? I think we concluded at the time that it wasn't needed, but still left the change in. I just noticed now that we have a function called Daemon.pm:get_new_bugtracker that Robert implemented that I ended up not using when I adjusted his patch. Do we perhaps need to convert the global Daemon.pm:$bugtracker variable to be local (per thread) ? I believe we chose not to because we preferred to have the daemon report possible configuration or package dependency errors related to the bugtracking backend as soon as the daemon started instead of when a connection was received. Given that the threaded implementation worked for me under Linux, for me under Windows, and for Thorsten under Windows, I assumed that this "sharing business" was never a problem. Could this have something to do with what OS you are using ? How the OS implements sharing code after a fork or thread creation ? But then both Thorsten and you are running the same OS (Windows Server 2003). Why does Thorsten's environment work and yours doesn't ? This doesn't make much sense.
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
