On Sat, Jun 22, 2013 at 10:00 AM, Roderich Schupp
<roderich.sch...@googlemail.com> wrote:
>
> On Thu, Jun 20, 2013 at 8:51 PM, Fulko Hew <fulko....@gmail.com> wrote:
>>
>> > [Ultimately, I'm doing this under Cygwin,
>
> You are aware of the fact, that an executable packed on Cygwin will
> NOT work on a machine without a minimal Cygwin environment?

Yes, I have found the minimum list of Cygwin files that I also need to
provide with it.

>> but... when the 'service' is stopped, its srvany that gets signaled
>> and not mintty let alone myapp.  But that's another hurdle I have
>> yet to surmount.]
>
> Note that on Windows (or any OS when you use "pp --clean ...") the pid
> of the running packed executable (as reported by the OS) and
> that of the actual perl process (as reported by $$ in perl) are DIFFERENT.

Thats OK.  The Windows 'srvany' issue is limited to 'srvany'.
Apparently there is no way for the stopping of the instance of srvany to
also 'stop the instance of the application it is controlling'.  So my app
keeps on running even when the 'service' is stopped.  so in the end there
is no way to let the PAR'ed app to 'clean up' when done.

>> So I made a simple 'hello world' as a test, that does a sleep to allow
>> me to control C it. and If I do... stuff is left behind.  What am I doing
>> wrong?
>
> Nothing, that is expected behaviour.

... snip ...

>> if I let it terminate, I'm still left with the empty /tmp/par-xxx
>> directory
>
> Behaves as expected - the top -level temp directory is never cleaned
> automatically.
>
>> (but eventually I'll get many different par-nnn directories!
> No. There is only one /tmp/par-xxx directory per user.

Sorry, I was wrong.  What I was seeing was many temp-nnn subdirectories.
I think I now have it limited to no temp-nnn stuff, but simply cache-nnn stuff.
that doesn't grow on subsequent invocations.  I can live with that.

I was trying to understand the PAR_GLOBAL_TEMP and PAR_CLEAN section
of the PAR.pm and one scenario (what if both are _not_ set) is not described.

I've tried PAR_GLOBAL_TEMP=/tmp/myapp (at PAR'ed application run-time)
and I still get temp-HASH directory created rather than a 'myapp' directory.
I wanted to do that to ensure that there was only a single set of cached info
regardless of the number of invocations (because I was seeing multiple
temp-nnn directories!

Reply via email to