|
Huzaifa Tapal
huzaifa at hostway.com
Mon May 2 22:19:54 EDT 2005
Hello Nicolas, What I am really worried about is that in a multi-threaded environment, accessing a modular level method, multiple threads might be accessing the same method at the same time and overwriting the other threads path list as a result. As per your question, I create a _lock object on top of the module. Pretty much this method was created in a "SharedResources" module as a modular level method. My framework then imports the method and uses it within to fix the paths. What do you think? Hozi Nicolas Lehuen wrote: >Hi Huzaifa, > >Well, that's really up to you, especially since I don't understand >where the _lock variable comes from. > >If it's not possible to change the path list which is passed as a >parameter without acquiring the lock, then why not, but I'd put the >locking mechanism in the calling code rather than in this function. >Note that you are not modifying the path list in-place : you just >return a copy of the path list with some fixes in it. So there is no >need to lock anything here, except if you fear that the path list will >be changed during the iteration, but for that, you have to put a >locking mechanism somewhere else for any modification of the path >list. So my first advice is : keep all locking code in the same place >and you'll save time and mental health :). > >My second advice is : don't be over-protective at the cost of >performance. Trust the users of your code. Provided that they have a >proper documentation, it's not necessary to lock anything, because >your users will know that bad things will happen if they change the >path list during iteration, so they'll do the right stuff accordingly. >Likewise, it's not necessary to check whether path is a list, or >whether some path entries are None or "". If your users want to give >silly data to your function, let them do it, and let Python throw >exceptions at them. > >Regards, > >Nicolas > >On 4/29/05, Huzaifa Tapal <huzaifa at hostway.com> wrote: > > >> I wanted to ask for a piece of advise. So the fix that I have mentioned, I >>moved that fix (the method I replaced with the map(lambda) solution you had >>with a minor fix) to another "SharedResources" module that I import in my >>framework's handler. From within the handler and my app, I am call that >>method passing in a path argument that it *fixes* and returns back the >>results. Here is what the new method looks like: >> >> def fix_paths( path ): >> """ Convenience method for checking and >> adding '/' to the end of paths for compatibility >> with mod_python's import_module. """ >> >> _lock.acquire() >> try: >> if path and type(path) == type([]): >> path = map(lambda entry : (entry!='' and entry[-1]!='/' and >>entry+'/') or entry,path) >> >> return path >> finally: >> _lock.release() >> >> Should I have the thread-locking in place or can I get by without having it >>in place? The reason I did add that was because the path value may get >>changed, in the process, I thought of making this method thread-safe. >> >> Also Nicolas, if you notice I added another check in your lambda function >>to check if the entry is an empty string. If that wasn't there then if an >>empty string path was passed in the list paths, the function would break. >>Thought, i'd let you know if you were gonna add this functionality into the >>import_module method for apache.py >> >> Thanks >> >> Hozi >> >> >> Nicolas Lehuen wrote: >> Sorry, reposting to the whole list : >> >>Hi, >> >>The change I've made for MODPYTHON-9 affects only the publisher >>module. It solves the problem encountered when you had two pages, one >>at /index.py, and the other at /foobar/index.py. >> >>Huzaifa, what I don't understand here is whether moduleA has the same >>name as moduleB, and whether you are using mod_python.publisher or >>not. >> >>If you use the publisher, your problem has been solved in the latest >>development version, and the fix will be in the next release. >> >>Anyway, if we put aside the fix specific to the publisher, the problem >>you describe is real, and the workaround you provide is correct. >> >>It is so correct that the only way I see of fixing that is to >>integrate the workaround in the import_module function, that is to say >>to check whether each path component passed in the path list argument >>ends with a '/' (or '\'), and if not, add a '/' (or '\\'). This is >>done easily in the first line of the function : >> >>if path: >> path = map(lambda entry : (entry[-1]!='/' and entry+'/') or entry,path) >> >>However, there is no easy way of telling what directory separator >>should be used ; theoretically, os.sep gives us the correct directory >>separator, but even under Win32 Apache admins are advised to use "/" >>which is compatible (at the OS level). So, we might as well always use >>"/". >> >>What I fear is that adding all these checks to import_module will make >>it a little bit too slow, so what about adding a line or two in the >>documentation about the fact that all directories mentioned in the >>path argument should end with a '/' ? >> >>Regards, >> >>Nicolas >> >>On 4/29/05, Graham Dumpleton <grahamd at dscpl.com.au> wrote: >> >> >> Nicolas, does the change you have already made for MODPYTHON-9 >>also address this slightly different variation on the problem? >> >>Original report was based on same name module in parent and child >>subdirectories, not sibling directories which share a common prefix >>to the subdirectory name. >> >>Graham >> >>Huzaifa Tapal wrote .. >> >> >> For my fix, I patched this issue by passing the import_module function >>the path with "/" in the end. That way it distinguishes from >>/home/user/dir1 and /home/user/dir123 >> >>hozi >> >>Graham Dumpleton wrote: >> >> >> >> See: >> >> http://issues.apache.org/jira/browse/MODPYTHON-9 >> http://issues.apache.org/jira/browse/MODPYTHON-10 >> http://issues.apache.org/jira/browse/MODPYTHON-11 >> >>There are various known issues with using same name module in different >>directories. >> >>The first one has been addressed for next version of mod_python. >> >>Graham >> >>On 29/04/2005, at 8:22 AM, Huzaifa Tapal wrote: >> >> >> >> I think there is a bug in apache.import_module. I am using >>apache.import_module passing in the path where I want the module >>imported from. I am seeing a very odd result as to sometimes, the >>module that is loaded is not the right one. Instead it loads a >>module that is of the same name but in a different directory. Here >>is what is happening: >> >>I have two modules of same name in 2 different directories as follows; >> >>/home/user/dir1/moduleA >>/home/user/dir123/moduleB >> >>Lets say I restart apache and load up moduleA. At that point there >>is an entry in sys.modules for moduleA. Lets say then, I load up >>moduleB, now the original entry for moduleA is overwritten by this >>new entry. Now when I go back to load moduleA, I get back moduleB >>results. Here is why: >> >>In apache.import_module if I pass in the path to load moduleA from >>'/home/user/dir1' and the last module was in '/home/user/dir123' then >>the check in import_module to make sure both modules aren't the same >>fails since it does a "file.startswith()" check on the path. Since >>the path moduleA is in the path to moduleB, it loads the wrong module. >> >>I see that somebody else had complained about this problem in >>mod_python 1.3.1 but it still has not been patched. >> >>Any ideas? >> >>Hozi >> >> >>_______________________________________________ >>Mod_python mailing list >>Mod_python at modpython.org >>http://mailman.modpython.org/mailman/listinfo/mod_python >> >> >> >> _______________________________________________ >>Mod_python mailing list >>Mod_python at modpython.org >>http://mailman.modpython.org/mailman/listinfo/mod_python >> >> >> _______________________________________________ >>Mod_python mailing list >>Mod_python at modpython.org >>http://mailman.modpython.org/mailman/listinfo/mod_python >> >> >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20050502/0485cc08/attachment-0001.html
|