[Python-Dev] Pondering some changes to python.c... (original) (raw)

Guido van Rossum guido@python.org
Tue, 09 Apr 2002 10🔞56 -0400

[me]

>This sounds awfully ill-defined. Do you know how this is accomplished >on various Unix variants besides Linux? What if there's some platform

[Sean]

I got this mechanism by examining sendamil (which uses the ps output to display various states). Sendmail includes 6 mechanisms for setting the process name:

pstat() psstrings (a struct you can set argc/argv through) sysmips() Apparently a SCO-specific mechanism which directly accesses kernel memory Overwriting the original argv[0] Setting argv[0] to point to a new buffer I have no idea how "published" one should consider these interfaces...

Oh, yuck. Bah. Please go away. :-)

>guaranteed to work as Linux is upgraded? I'd hate to hear the >complaints from users when they upgrade their kernel and find that it >breaks Python, despite ABI compatibility promises.

Indeed. It's small consolation that it would also break sendmail... >What code would have a hold of argv, except main() which just calls >PyMain()? In the normal python interpreter, nothing. My concern was more with a system that embeddeds Python... Which is why I'd lean more towards an implementation which required an explicit initialization call to enable. That would signal Python that the embedder knew of and condoned the modification of the process string. I'm torn between making it a build-time option in the SRPM (defaulting to disabled) and just dropping it as "too contentious". Sadly, the least objectional way to make it happen is probably making it os.pstat() and wrapping the pstat() system call on the platforms that have it. "Sadly" because Linux doesn't seem to be one of those platforms...

Let's just drop it.

--Guido van Rossum (home page: http://www.python.org/~guido/)