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:
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
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)
Possibly. Which I expect would give maybe tens of megabytes of page
tables. Which should take approximately no time at all to copy.
But you’d still need to copy the pages themselves too, which is where
the real problem arises…
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()!
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).
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?
Sylvain Becker <sylvain.becker at gmail.com> writes:
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 ?
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.
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 <@Sylvain_Becker> writes:
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 ?
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.
Sylvain Becker <sylvain.becker at gmail.com> writes:
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).
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
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:
Den 10. feb. 2015 08:52, skrev Sylvain Becker:
As suggested, I have updated the patch to fork twice so that the
application cannot be blocked.
I don’t think you can vfork twice like that. You can call exec*, or _exit,
and that’s it. Just use fork
Also, could you use execlp with “xdg-open” as the path instead of execl?
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:
Has there been any more developments on this? I was hoping to see it
included in 2.0.4.
