New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix hang in test/26fork.t on Win32 #32
Conversation
Updated the commit, the first one had a race condition and I saw the lock was ignored (my mistake) after I tested the locking ability with warn statements.
The |
Repushed. Fixed "cannot unlink file for C:\sources\inline-c-pm_Inline_26fork.7304\lib\auto_26fo
|
Repushed, included the stuff from 1739b57 which was a patch to an older removed commit. |
Repushed, changed sterilization of the mutex name per MSDN docs (no thanks to Win32::IPCs docs which havent been updated in more than a decade). The starting the name with "C:" always failed. Adding 'Inline__C_' made it not fail, most of the time atleast, except in 27inline_maker.t where it too failed. So removing all the fwd slashes fixed 27inline_maker.t and it passes for me now (I had to uncomment the win32 skip all). |
Any updates? |
@bulk88 I'm waiting for someone to figure out why t/27 fails. |
This commit doesn't touch file 27inline_maker.t . 27inline_maker.t working on Win32 was just a fun fact I discovered. I reverted to CPAN 0.67 without the patch in this PR, tested 27inline_maker.t and it passed. So this patch is not needed for 27inline_marker.t to pass. I'm not sure where 19ae41b came from PR/Issue ticket wise so IDK why it was marked failing. When you figure out why 27inline_maker.t doesn't work on non-Win32 you can uncomment the Win32 OS too at that time. Or uncomment 27.t on Win32 only today, independent of this PR. I'd like to see this PR done with soon so I can delete my repo. |
On I-C-0.64 27.t fails for me on Windows7 quite drastically and in a bizarre
Cheers, |
@bulk88, Win32::Mutex is a CPAN module and I'd like to avoid dependencies. Can you please redo this using eg |
From IRC #win32:
Dynamic dep facility is because obviously we don't (need/want to declare) a dependency on |
26t became stable because I used Win32's native Kernel provided synchronization APIS. Not a hacked up API of using flock for syncronixation,. Using native Win32 IPC is going to be better than try hacked up attempts that dont even reach the claims they show off. |
ATM I am refactoring Win32::IPC (Win32::Mutex is distributed in Win32::IPC). Should I make Win32::Mutex build and install (but not provide any subs on Unix for obvious reasons) on Unix and release it to CPAN? |
See ingydotnet#31 for bug description.
This reverts commit 256e470.
Fixed |
See #31 for bug description.
The test now passes (doesn't hang).
remaining problem is either to sleep more until the dll is unloaded or use forceunlink() from ExtUtils::Install which renames the dlll.