On Sat, 15 Aug 2009 14:26:47 +0200, "Hans-Peter Jansen" <[email protected]>
wrote:
> Am Donnerstag, 13. August 2009 schrieb Hans-Peter Jansen:
>> Dear Giovanni,
>>
>> Am Donnerstag, 13. August 2009 schrieb Hans-Peter Jansen:
>> > [Sorry for cross-posting]
>> >
>> > Hi,
>> >
>> > attached script demonstrates an ugly issue, I'm fighting with since a
>> > couple of days.
>> >
>> > Issue:
>> > when starting the app via double click, single click on dock icon,
>> > dropping a plain/text file on dock or application icon, all actions
>> > lead to two icons bouncing. The one with the blue spot is the good
one,
>> > that stops bouncing after start-up. The bad one will stop bouncing
>> > eventually, and shows "Application not responding" in its context menu
>> > then. As long as the bad one exists, dropping files on the good one
>> > will be ignored. After killing (and sometimes removing from the dock
is
>> > necessary) all is well - one can drop files one the good one, and it
>> > behaves well, up to the point of being terminated, then the game
starts
>> > again.
>> >
>> > It's not depending on the arch, but on OS-X 10.5. It does not happen
>> > with 10.4. It is may be related to pyinstaller, but since I need to
>> > deploy the app on arbitrary 10.4 and later systems, omitting it is not
>> > an option.
>>
>> I think, this issue is due to this fork:
>> pid = fork();
>> if (pid == 0)
>> execvp(thisfile, argv);
>> wait(&rc);
>>
>> Since termination of the bad process is accompanied with these syslog
>> messages:
>> Aug 13 19:01:26 g5 com.apple.launchd[124]
>> ([0x0-0x130130]..local.LaunchProb[9611]): Stray process with PGID equal
>> to this dead job: PID 9612 PPID 1 LaunchProb
>> Aug 13 19:01:26 g5 com.apple.launchd[124]
>> ([0x0-0x130130]..local.LaunchProb[9611]): Exited: Terminated
>>
>> I suppose, it's due to the fork. Could you briefly explain, why this
>> fork() is necessary, since it forks into the same binary already
running.
>>
>> Thanks,
>> Pete
>
> Update: No, it's not the fork, since disabling it with a patch similar to
> the attached one does produce the exact same behavior. Giovanni, the
> question about the necessity of this fork persists. Would you be so kind
to
> elaborate on this a bit, please?
The fork is needed to be able to set {DY}LD_LIBRARY_PATH correctly, since
modifying the environment does not take effect on the running process.
Moreover, for one-file builds, it makes it sure that the temporary
directory is removed, even if the program (executed in the child program)
exits with a segfault or similar abrupt exit.
As for the whole problem, I think it was already handled by PyInstaller, at
least in one-file mode, when using a bundle. Are you using the Bundle()
command of PyInstaller? It sets LSBakgroundOnly in the internal XML file,
and that should make the trick. There is also a comment to that effect
within Build.py.
PS: I'm on vacation, I'll be back on August 24th and I will check your
testbed.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pyinstaller?hl=en
-~----------~----~----~----~------~----~------~--~---
