Still valid for Strawberry perl 5.22.1.1 64bit on windows 8.1

Still happening in 0.12 under Strawberry Perl 5.22.2 32bit etc on Windows 7(32bit).

I think that it is caused by an autovivification in line 212 of Simple.pm.

This patch might be helpful.
Filesys-Notify-Simple-0.12.gh-16.patch.txt

P.S.
Even if this is applied, for example, if you execute the following command:

C:\work>plackup -r hello.psgi

(1) Filesys::Notify::Simple watches all files and directories directly under c:\work.

(2) "plackup -r" will not function why.
My Workaround about (2)
(
Please read RT:
Bug #40565 for perl5: Windows fork emulation's child pseudo process cannot restore local scalar values
Report information
)

C:\work>plackup -L Shotgun hello.psgi

Shotgun loader uses fork(2) system call to create a fresh Perl interpreter, that is known to not work
properly in a fork-emulation layer on Windows and cause huge memory leaks.

If you're aware of this and still want to run the loader, run it with the environment variable
PLACK_SHOTGUN_MEMORY_LEAK on.

Compilation failed in require at C:\home\journey\perl5\lib\perl5/Plack/Util.pm line 26.

C:\work>set PLACK_SHOTGUN_MEMORY_LEAK=1

C:\work>plackup -L Shotgun hello.psgi

Hope this help.

Thank you,

--
twata

Hey @twata1, could you test my pull request #23 if this fixes your issue too?

IMO there is a deeper problem with the windows file watcher, as it can only watch whole directories. Therefore we need to filter "unwanted" events in case we watch specific files. Which is what my PR does.

I have successfully tested it against perl-libsass watcher on linux and windows.

Hi, @mgreter

I tested #23.

[Test environment]
Windows 7 Pro(32bit)
Strawberry Perl 5.22.2(32bit built for MSWin32-x86-multi-thread-64int)

[Test files and directory]
c:\work\hello.psgi
c:\work\aaa.txt
c:\work\lib\a.txt
c:\work\lib\abc\b.txt

[Test]

C:\work>plackup --version
Plack 1.0044

C:\work>plackup -r hello.psgi
HTTP::Server::PSGI: Accepting connections at http://0:5000/
Watching ./lib hello.psgi for file updates.

modified aaa.txt.

-- C:\work\aaa.txt updated.
Killing the existing server (pid:-4408)

Certainly, the following message disappeared.
Don't know how to wait on $objects[0] at...
(Although the message 'Killing the existing server (pid:-4408)' is output as described above,
"plackup -r" does not function yet.
Specifically, after updating the file, if you visit http://127.0.0.1:5000/hello.psgi in the browser, you will not receive a response(timeout) or see the file before update.
)

Hi @twata1, you're probably facing https://curiousprogrammer.wordpress.com/2010/03/22/plack-auto-restart/ - fork/signal handling (which plack uses) work very different on windows (the negative pid indicates that it is indeed a thread and not a forked process). Seems the fix to send a KILL signal (kill 'KILL' => $pid) in Plack/Loader/Restarter.pm is the only easy fix available (with all implications that go with it).

Hi @mgreter

Thank you for the information.
I created a patch.
Plack-1.0044-Plack-Loader-Restarter-Win32.patch.txt

I applied the patch above and tested #23

C:\work>plackup -r hello.psgi
HTTP::Server::PSGI: Accepting connections at http://0:5000/
Watching ./lib hello.psgi for file updates.

modified aaa.txt.

Killing the existing server (pid:-8040)
Successfully killed! Restarting the new server process.
HTTP::Server::PSGI: Accepting connections at http://0:5000/

But, after updating the aaa.txt, I visit http://127.0.0.1:5000/hello.psgi in the browser, I can't receive a response.

Anyway, thank you for the information!

Looks like one of the implications of just killing the child thread holding the listening socket. The only crude workaround would probably be to exit the main process too and just restart plackup with a batch file:

:while
call plackup -r hello.psgi
if %errorlevel% == 1 goto :while

     my $pid = $self->{pid} or return;
     warn "Killing the existing server (pid:$pid)\n";
     kill 'TERM' => $pid;
+
+    if ( $^O eq 'MSWin32') {
+        sleep 1;
+        kill 'KILL' => $pid;
+        waitpid($pid, 0);
+        exit 1;
+    }
+
     waitpid($pid, 0);
 }

BTW: Sorry all that we highjacked this thread ;)

I'm sorry too.
I tried to 'restart plackup with a batch file':

:while
call plackup -r hello.psgi
if %errorlevel% == 1 goto :while

with patched Restarter.pm(Plack-1.0044-Plack-Loader-Restarter-Win32.patch.txt).
But I got same reproduction of the results.

Finally, I found:

Crude Win32 development restarter

and server-restarter.pl works fine.

So, I wanted to test #23 without using plack.
I decided to test using CSS::Sass version 3.4.9.
Regardless of whether or not to apply #23,
command psass -w did not work under Strawberry Perl 5.22.2
(I am going to create an issue to CSS::Sass).
So, I tested under Strawberry Perl 5.24.0.

[Test environment]
Windows 7 Pro(32bit)
Strawberry Perl 5.24.0(32bit built for MSWin32-x86-multi-thread-64int)

[Test files and directory]

 c:\work\hello.psgi
 c:\work\aaa.txt
 c:\work\lib\a.txt
 c:\work\lib\abc\b.txt
 c:\work\sass\body.sass
 c:\work\css\body.css

[Test]

C:\work>perl -MCSS::Sass -e "print $CSS::Sass::VERSION;"
3.4.9
C:\work>perl -MList::MoreUtils -e "print $List::MoreUtils::VERSION"
0.426
C:\work>perl -MList::MoreUtils -e "print $List::MoreUtils::XS::VERSION"
0.426
C:\work>perl -MFile::Slurp -e "print $File::Slurp::VERSION;"
9999.19
C:\work>psass -v
psass 0.5.0 (perl sass/scss compiler)
  libsass: 3.4.7-gcc44
  sass2scss: 1.1.1

C:\work>psass -w .\sass\body.sass .\css\body.css

syswrite() is deprecated on :utf8 handles at C:/Strawberry/perl/vendor/lib/File/Slurp.pm line 506.
==============================================================================
waiting for changes now
  C:/work/sass/body.sass
==============================================================================

Certainly, the following message disappeared from above output.
Don't know how to wait on $objects[0] at...

modified body.sass

changed: C:\work\sass\body.sass
compilation started
syswrite() is deprecated on :utf8 handles at C:/Strawberry/perl/vendor/lib/File/Slurp.pm line 506.
sucessfully finished
 0 wallclock secs ( 0.00 usr +  0.00 sys =  0.00 CPU)
==============================================================================

Certainly, I confirmed body.css was compiled.
Therefore, It seems to me that #23 works fine.

Thank you,