-
Notifications
You must be signed in to change notification settings - Fork 2.1k
[WIP] [Process] Add functions to get current process PID and name #12666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
MrOnlineCoder
wants to merge
1
commit into
libsdl-org:main
Choose a base branch
from
MrOnlineCoder:feature/get-current-process
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+172
−0
Draft
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,28 @@ | ||
/* | ||
Simple DirectMedia Layer | ||
Copyright (C) 1997-2025 Sam Lantinga <[email protected]> | ||
|
||
This software is provided 'as-is', without any express or implied | ||
warranty. In no event will the authors be held liable for any damages | ||
arising from the use of this software. | ||
|
||
Permission is granted to anyone to use this software for any purpose, | ||
including commercial applications, and to alter it and redistribute it | ||
freely, subject to the following restrictions: | ||
|
||
1. The origin of this software must not be misrepresented; you must not | ||
claim that you wrote the original software. If you use this software | ||
in a product, an acknowledgment in the product documentation would be | ||
appreciated but is not required. | ||
2. Altered source versions must be plainly marked as such, and must not be | ||
misrepresented as being the original software. | ||
3. This notice may not be removed or altered from any source distribution. | ||
*/ | ||
|
||
#ifndef SDL_process_c_h_ | ||
#define SDL_process_c_h_ | ||
|
||
extern void SDL_InitProcessManagement(void); | ||
extern void SDL_QuitProcessManagement(void); | ||
|
||
#endif |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will return the invocation name as found in argv[0], and is incorrect when symlinks are used. Your idea to split the executable path functionality out of the base path functionality is probably the way to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could replace the rather bare-bones SDL_GetExeName() functionality in src/core/unix/SDL_appid.c as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please help me clear the confusion on where to actually implement the function for fetching the executable name, or to be exact, what should be the cross-platform approach to it.
We have quite a few platfrom-dependent implenentations for
filesystem
module: android, cocoa, haiku, gdk, ps2, psp, unix, windows, vita, etc... While forprocess
we have only division into windows and unix. Is this because process creation is more standardized than filesystem access? Or does it mean process API may not be supported on some systems like ps2 or haiku?Some of the
SDL_GetBasePath
implementations do not parse the directory name out of executable path, for example Emscripten just uses "/" as a return value, and PS2 returnsgetcwd()
, which means not every SDL_GetBasePath implementation may contain a valid way to achieve the executable path, that can be used to split into two functions as mentioned above.How should I proceed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MrOnlineCoder
No, I only meant the actual executable (as stated by the workaround of using args[0], being path-free). In case you do want such checks for the exe source path, we already have SDL_GetBasePath. So a supposed SDL_GetCurrentProcessName() would return myapp (for POSIX) or myapp.exe (for win-like systems).
I also stated the ideal way is to cache it for further access since it won't change, similar to SDL_GetBasePath.
Indeed no. You'd need #ifdefs unfortunately. See SDL_GetExeName() as a starting point.
What I found by looking around (but I don't have a *nix to test them on):
@Kontrabant
Well, technically speaking it is still correct. While not talking about games, at work a very modular production system uses configurable modules for each component and it has only dedicated executables on a *nix system but we have over 40 components starting as processes and each are started as a symlink to the what exe is proper for that component. The way we monitor them is to see the "exe" that started it, which is the symlink. If we had resolved the symlink, we wouldn't know what component we're actually monitoring when it initiates (before configs are loaded and so on). While I know I am talking about enterprise systems here, let's consider SDL can be used for other types of apps as well, not just games :) There are built-in ways to treat this and for those using C++, the filesystem namespace is very easy to use, so I wouldn't worry about it. OTOH, the only reason I proposed argv[0] was as a workaround if the system won't allow a method for that due to sandboxing (I am thinking maybe consoles or some mobile devices possibly?)
Indeed, it's good as a starting point since it covers most
With the mention that the process name should not contain the path; it's not the same as a pseudo-GetCurrentExeFilePath.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MrOnlineCoder
Not sure it's the best way, but good starting code that I imagine would probably be (this is more or less pseudo code, as I am just typing it here, so typos or compilation errors might occur, but might serve as a starting point; consider some is also guess work :) ):
Process id
include/SDL_process.h
extern SDL_DECLSPEC SDL_ProcessID SDLCALL SDL_GetCurrentProcessID(void); // SDL_ProcessID maybe? depends if the type is different on each platform
src/process/SDL_sysprocess.h
SDL_ProcessID SDL_SYS_GetCurrentProcessID(void); // (or hardcoded type? see above note)
src/process/windows/SDL_windowsprocess.c
src/process/posix/SDL_posixprocess.c
src/process/SDL_process.c
EXE name
include/SDL_filesystem.h
extern SDL_DECLSPEC char * SDLCALL SDL_GetCurrentExe(void);
// or SDL_GetCurrentExeFilename?src/filesystem/SDL_sysfilesystem.h
extern char *SDL_SYS_GetCurrentExe(void);
src/filesystem/windows/SDL_sysfilesystem.c
src/filesystem/cocoa/SDL_sysfilesystem.m
Bundled app: executablePath
Non-Bundled app: _NSGetExecutablePath
src/filesystem/dummy/SDL_sysfilesystem.c
src/filesystem/emscripten/SDL_sysfilesystem.c
No clue
src/filesystem/gdk/SDL_sysfilesystem.c
src/filesystem/haiku/SDL_sysfilesystem.c
See this example
src/filesystem/n3ds/SDL_sysfilesystem.c
Most likely no way to get it
src/filesystem/posix/SDL_sysfilesystem.c
src/filesystem/riscos/SDL_sysfilesystem.c
As far as I could see from the documentation at first glance, there is no way to track the currently running image reliably
src/filesystem/unix/SDL_sysfilesystem.c
src/filesystem/vita/SDL_sysfilesystem.c
Doubtful it can be done on Vita
src/filesystem/SDL_sysfilesystem.c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MrOnlineCoder
Regarding the examples, I am hoping they help you even if a little. They were based on some quick research (as I don't have those platforms) after reading up on the APIs and some articles. Which is also why I can't assure you on their validity.
I don't have those platforms, so I can't test. I am sure there are SOME edge cases, but I wouldn't focus on them as those might be the exception, not the rule. And to be fair, the general programming law is: "I coded this to be used properly as so, I added some protections or workarounds if you call it wrongly like so so that it still works right, but if you bypass those and the app behaves incorrectly, I am not responsible for your stup... pro-activeness" :)
For the exe name function , I recommend you move it to the filesystem category (see my suggestions) and call it SDL_GetExeName (or SDL_GetExecutableName or SDL_GetCurrentExeFilename or whatever else) since it's more of a file-thing than a process thing. Processes have ids or handles, but my topic addressed the process name just to give a general idea.
Also, make sure you remove the pathname to the exe in the pseudo-getexe function. I think if someone does want to see how it was launched (i.e. via some relative path or from the home directory or anything other, they can capture / track main() or WinMain(). As for symlinks, as I said, I don't recommend a resolution on them. Or if you did implement it (I didn't check), make it customizable via a macro. This way if someone wants to track a symlink / shortcut intentionally to diferentiate something versus someone wanting to track a symlink / shortcut to make sure nobody altered the app, they have the full freedom to do so.
I'll check your progress when I get home from work.
P.S. I also got thinking about closed systems and either the dev can use a workaround like SDL Proprties for that, either they hardcode it (it's not like you can change or add a new executable on consoles anyway) so I don't think there is work needed there. If somebody does complain, a simple SDL_SetExeName() would suffice (to keep code portable and not fall back to workarounds like properties).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MrOnlineCoder
Please check the above advice, also note the issue was auto-closed on libsdl, even though it was not fully implemented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MrOnlineCoder
Please check the above advice, also note the issue was auto-closed on libsdl, even though it was not fully implemented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thedarknomad hey sorry for late reply, didn't have time to work on that one. What do you mean the issue was auto-closed? The #12615 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind, I didn't read the message carefully, ignore the closing thing I said.