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.
Cheers,
Mark
--
http://mail.python.org/mailman/listinfo/python-list
