On 05/02/2009 8:26 PM, Mark Hammond wrote:
On 6/02/2009 2:50 PM, Mark Hammond wrote:
On 6/02/2009 11:37 AM, Volodya wrote:
Hi all,
I think I've found a small bug with multiprocessing package on
Windows.
I'd actually argue its a bug in pythonservice.exe - it should set
sys.argv[] to resemble a normal python process with argv[0] being the
script. I'll fix it...
Actually it appears I spoke too soon:
* A bug in pywin32 exists such that when you use 'debug' on a service,
the argv reflected the full argv of the application, including the
'-debug' portion of the command-line. However, even if that is fixed,
the next argument is actually the name of the service (as declared in
the .py file for the service), not the .py module itself. Thus, I
could make argv a little more sane in this case, but still the initial
problem would remain as argv[0] would still not be a .py file.
* When the service is started by windows itself, there are usually
zero additional command-line arguments. If there *are* arguments,
they are likely to be the string the user entered via control panel as
a special case (Windows doesn't actually remember service args - they
are used once and discarded). It is important we continue to expose
whatever argv we actually got from Windows to the service code.
So unfortunately I don't think I can change pythonservice to resolve
the issue you reported.
Thanks Mark, this makes perfect sense.
In the patch I submitted, I simply check if the name of the supposed
module ends with ".exe". It works fine for my case, but maybe this is
too general. Is there a chance that a Python module would end in ".exe"?
If so, maybe we should check specifically for "pythonservice.exe". But
then, if someone renames the executable (as I did, because I wanted to
see meaningful service names in the process list), the patch will not
work. Maybe there's another way to fix the forking module?
--
http://mail.python.org/mailman/listinfo/python-list
