SDL_OpenURL proposal |
slvn
|
I have added a first version of "SDL_OpenURL" function for Android and Unix.
It works with URLs, and probably with directories and files. It would be nice if someone could add MacOSX, IOS, Windows, etc. see the patch: https://bugzilla.libsdl.org/show_bug.cgi?id=2783 On Fri, Nov 21, 2014 at 9:42 AM, Eric Wing wrote:
-- Sylvain Becker _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL_OpenURL proposal |
Gerry JJ
Guest
|
The Unix code is broken :/
- It may or may not block, depending on the browser - It doesn't escape the URL in any way. It'll expand variables, lose quotes, split at & and partially execute the URL, etc. Or just insert a semicolon and run anything you want. -g Den 06. feb. 2015 16:31, skrev Sylvain Becker:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL_OpenURL proposal |
slvn
|
You're right !
- I am not sure about how to solve the blocking/non-blocking browser. - The patch is updated: I changed the call to "system()", by a call to "execl()" (and fork()) so that the URL argument is protected in a better way. thanks, Sylvain On Fri, Feb 6, 2015 at 7:21 PM, Gerry JJ wrote:
-- Sylvain Becker _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
SDL_OpenURL proposal |
Alexander Sabourenkov
Guest
|
I would recommend using vfork() instead of fork().
Blocking/non-blocking behavior depends on desktop environment, not browser. xdg-open is just a shell script wrapper, see here - http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open.in In absense of a desktop environment it falls back to run-mailcap and mimeopen, in that order. I have no idea if that may block (probably), if any supported DEs' launchers may block (xfce4's does not), and if going asynchonous (waiter thread, success/no-success message/event injected into event queue, quite a bit of code and complexity) is in fact worth it. Might be better to note that the function may block and leave it at that for now. |
|||||||||||
|
SDL_OpenURL proposal |
Alexander Sabourenkov
Guest
|
Also please use _exit() instead of exit().
|
|||||||||||
|
SDL_OpenURL proposal |
slvn
|
Thanks for the explanation.
I have updated "fork" to "vfork" and "exit" to "_exit". Just wondering if calling "posix_spawn()" wouldn't be better? I have also added the MacOSX and IOS part. Please can someone double-check thoses functions as I don't really know cocoa/uikit ! (like missing memory release of objects, incudes, ...) On Sat, Feb 7, 2015 at 6:49 PM, Alexander Sabourenkov wrote:
-- Sylvain Becker _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL_OpenURL proposal |
Eirik Byrkjeflot Anonsen
Guest
|
Sylvain Becker writes:
Actually, fork() is usually preferred over vfork(). The semantics of fork() are simple, while vfork() can easily get you into undefined behaviour. ("the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit(2) or one of the exec(3) family of functions.") And the advantages of vfork() are unlikely to be useful in this case. posix_spawn() would surely be a potential alternative. I don't think it really matters which one you use. When it comes to blocking behaviour, the problem lies in the fact that you are waiting for the new process to end. Just remove that and you won't have blocking behaviour any more. However, that creates a new problem with zombie processes. You do want to wait for the process eventually. As long as you don't really care about the new process once you've started it, this can be solved by forking twice. Start the new process in the grandchild and immediately exit from the child. In the parent, you wait for the child. Since the child just forks and execs, that completes quickly and you have no blocking. At this point the child process is gone, so the grandchild (which is the one doing the exec()) is now orphaned. Orphaned processes are waited for by the init process (pid 1), so that will be handled automatically. eirik _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL_OpenURL proposal |
SDL_OpenURL proposal |
Eirik Byrkjeflot Anonsen
Guest
|
Alexander Sabourenkov writes:
Sure, but code changes. Someone changing the code and not noticing the "v" could break it. Or someone seeing the "v" might try to exploit the shared address space effect, something that is bound to break on some systems. Basically, what I'm saying is that vfork() is usually an unnecessary complication, for very little gain. That being said, I agree that the gain depends on the situation at hand, and I'll accept that SDL might just be one case where vfork() is worth it.
Without having tested this myself, I assume that the main advantage of vfork() is that you might be able to spawn thousands of processes per second rather than a handful. I don't see that as being very useful for a user-initiated one-off action. Of course, if my intuition about the performance of fork() is off and it can be expected to take a "long" time (whatever that is? half a second?) then I'll happily withdraw my objection And on second thoughts, I guess if you are trying to have smoothly animated graphics on the same thread as you are calling fork(), you could be in trouble. (I might think that you shouldn't be trying to have smoothly animated graphics on the same thread as arbitrary background processing, but that's just me.)
Not sure what you object to here. If you complain about my mentioning pid 1, I was merely pointing out that some process will indeed be wait()ing on the created process. Which is kind of important. (I'm sure you agree that the blocking is precisely because the main process wait()s synchronously for the potentially long-running child?)
If you have several gigabytes worth of page tables, I guess that means you have many terabytes of allocated memory. I think at that point the slowness of a fork() is the least of your problems
Small wastes in non-critical code doesn't worry me. Straightforward, "obviously correct" code is generally more important to me. And I always have to look up the particulars of vfork() whenever I see it used to be sure it is used correctly. But I guess it does depend on exactly how much of an advantage vfork() is over fork() for the use cases SDL caters for. And exactly how critical this path really is. Objection (mostly) withdrawn eirik _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||||||||
|
SDL_OpenURL proposal |
Sik
|
2015-02-09 13:11 GMT-03:00, Eirik Byrkjeflot Anonsen:
Having a separate thread may still not be useful if the operating system is exhausting all the current CPU resources in order to spawn a new process anyway. Yeah, nitpicking here, just don't think that you can spawn a new process and not have a serious slow down during the time it takes to start it
Sound like bad wording and he just meant gigabytes of pages. Still, given that games these days demand GBs of RAM in the system requirements, potentially needing that much copying would be an issue. I know that Linux only copies when the memory changes, but if the child process is blocking then that means it could be doing that for a long time (enough to result in lots of RAM being used up for no real reason). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL_OpenURL proposal |
Eirik Byrkjeflot Anonsen
Guest
|
Sik the hedgehog writes:
I'd still say it is useful. You'll have a lot more chance of reaching your 16 or 33 ms deadline at degraded performance than when waiting for a blocking call
Possibly. Which I expect would give maybe tens of megabytes of page tables. Which should take approximately no time at all to copy. Hmm, I see that I have an iceweasel (aka firefox) running, taking 2.2 GB of virtual memory, 800 MB of resident memory, and 3968 kB of page tables. (Unless I'm looking at the wrong numbers)
Yes, I was assuming that any reasonably modern system would implement fork() with some form of copy-on-page-required, leaving the process state and page tables the only thing that fork() actually have to copy (well, mostly). If SDL supports systems that requires fork() to copy the whole process's memory space, then by all means use vfork()! eirik _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||
|
SDL_OpenURL proposal |
Sik
|
2015-02-09 16:48 GMT-03:00, Eirik Byrkjeflot Anonsen:
What I meant is that you would not even attempt this in a situation where you don't need to miss the framerate mark in the first place (and anyway, given the whole point of this function is to open other program and give focus to it, framerate isn't even relevant here really)
But you'd still need to copy the pages themselves too, which is where the real problem arises...
For that kind of stuff there's usually an #ifdef to select between both methods. The thing is that as I mentioned the issue can even arise with copy-on-change, if the two processes stay around for too long (which is what's bound to happen if the call ends up being blocking). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
SDL_OpenURL proposal |
Daniel Gibson
Guest
|
On 02/10/2015 04:27 AM, Sik the hedgehog wrote:
Not if the fork()ed process exec()s - after that they shouldn't share any pages anymore. I'd suggest stopping to discuss about fork() vs vfork() and concentrate on how to best run that shellscript savely and reap the child later to prevent zombies. As this is a common enough task it shouldn't be that hard? Cheers, Daniel _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
SDL_OpenURL proposal |
slvn
|
As suggested, I have updated the patch to fork twice so that the
application cannot be blocked. Notice that the return code does not say anymore something about the success/failure of xdg-open, but now, is about the success/failure of the *launching* of xdg-open. PID should be collected and ended manually at the end probably ? On Tue, Feb 10, 2015 at 5:05 AM, Daniel Gibson wrote:
-- Sylvain Becker _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||
|
SDL_OpenURL proposal |
Eirik Byrkjeflot Anonsen
Guest
|
Sylvain Becker writes:
Not sure which pid you are talking about here. If you are thinking about the pid of xdg-open, you can just ignore it. That's really the point of forking twice. Since xdg-open is now orphaned, "init" (process 1) will reap it when it dies. I have not looked carefully at the code, only quickly read through the unix SDL_OpenURL() code, but it looks sensible to me. eirik _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL_OpenURL proposal |
slvn
|
Sorry, I did not explain myself correctly.
Yes, I mean't the xdg-open pid, when xdg-open is blocking because of the system configuration. For instance, xdg-open is blocking and opening the url/file with no window/shell/tty attached. Then those xdg-open process will last forever, because of no user interaction, even after the main sdl app has exited. Don't know if this configuration could happen. (this can be simulated easily, by replacing the launch of xdg-open in SDL_OpenURL, by the launching of a script that simply does an infinite loop). On Tue, Feb 10, 2015 at 8:15 PM, Eirik Byrkjeflot Anonsen wrote:
-- Sylvain Becker _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL_OpenURL proposal |
Eirik Byrkjeflot Anonsen
Guest
|
Sylvain Becker writes:
I see. Yes, that is a point. However, I don't think that is a situation you want to handle anyway. Consider what would happen if xdg-open replaces its process with the web browser. The user would probably not be happy if you kill their web browser. Also, once you start doing this, you'll have to properly track the process, which means doing some global work to wait() for the process again. Which just gets hairy. I think it is probably better to just assume that xdg-open is sane eirik _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL_OpenURL proposal |
Gerry JJ
Guest
|
Den 10. feb. 2015 08:52, skrev Sylvain Becker:
I don't think you can vfork twice like that. You can call exec*, or _exit, and that's it. Just use fork :p Also, could you use execlp with "xdg-open" as the path instead of execl? -g _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL_OpenURL proposal |
slvn
|
Updated patch.
Yes, you're totally right. The first forking must be done with "fork()" because it will then try to fork again (so it calls a function different from _exit and exec*, making "vfork()" not recommended there). Second forking can be done either with fork() or vfork(). (Even if it works my Linux distribution, it's seems to have some problem with others systems). Thanks for all comments. Also, Thanks to the original posters of this thread Alex and Eric, because the patch is mainly of copy-paste of their indications. I think, now, it needs also the windows patch. Which I can't do as I have no window platform ready for that. Would be nice to have someone to look at it. On Wed, Feb 11, 2015 at 4:56 PM, Gerry JJ wrote:
-- Sylvain Becker _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
AntTheAlchemist
|
Has there been any more developments on this? I was hoping to see it included in 2.0.4.
I don't know how to apply a patch... |
|||||||||||
|
SDL_OpenURL proposal |
slvn
|
I would like also to see this included.
Just to let people know that it currently works on android, ios, windows10, macosx, linux. But the patch is partially implemented. On 12 January 2016 at 17:56, AntTheAlchemist wrote:
|
|||||||||||||
|