Open shimondoodkin opened 8 years ago
Some of the above warnings can be fixed easily:
Regarding signals: lbzip2 uses signals for both event handling and inter-thread communication. SIGUSR1 and SIGUSR2 can be replaced by other forms of inter-thread communication. From what I just read, SIGTERM, SIGXFSZ and SIGPIPE are not generated under Win32 and Win32 creates separate thread for handling SIGINT. Therefore it looks like all signal handling code could be reduced to a single handler for SIGINT (Ctrl+C) and some form of inter-thread communication (eg. mutex and condvar). There should be no need for signal masks as the only external signal (SIGINT) is always handled in a separate thread.
Has any progress been made on this? lbzip2 would be incredibly useful on Windows,
I did all the rewrites I knew well and could do effectively.
I did not implemented the signalling rewrite.
The interthread communication requires to understand the communication why the threads communicate and what it tries to achieve and where it is in the source code. maybe the author can explain how the threads work.
בתאריך יום א׳, 2 באפר׳ 2017, 06:56, מאת CZauX notifications@github.com:
Has any progress been made on this? lbzip2 would be incredibly useful on Windows,
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kjn/lbzip2/issues/16#issuecomment-290963082, or mute the thread https://github.com/notifications/unsubscribe-auth/AATMYMea95EdvKVVLO26bm4rnveXAS2sks5rrxxegaJpZM4Jewy0 .
I will try to make lbzip2 build and work on MinGW. @shimondoodkin It would help if you could share your existing code.
I believe all my changes are in my fork https://github.com/shimondoodkin/lbzip2
@kjn @shimondoodkin I made a little attempt to build lbzip2 with MinGW, but there was quite enormous part missing, especially missing signal constants, file locking such as flockfile
etc. I dunno it replacing these parts with dummy implementations that return success if good way to go.
Additionally, gnulib dependency does not make it easier. Altogether looks like a lot of work to get it running natively on Windows.
Probably it would be easier to start when the project was based CMake for example not autotools, at least this would make it no more dependent on shell (Bash). This way pulling just GCC (e.g. x86_64-8.1.0-release-posix-seh-rt_v6-rev0
) out of MinGW would be sufficient - no need to install full environment. Just thinking loud.
Also maybe having it C11 would make all the threading and time calculation easier?
As far as I'm aware of only analogical, parallel compressor that was, or shall I say can be compiled under windows is pigz; with some minor patching incorporatedin version 2.6, and works fine. I use it personally. It uses its own interface to (p)threads. Also plzip is known to be used under cygwin, mingw (since version 1.8), not msvc. It uses pread/pwrite that are not supported in mingw nor in msvc but with patch included in mentioned version 1.8 it does very well - I never had a problem with it. Anyhow it's not thread related issue per se.
Reason I'm talking about that, is that - there is a path already paved and maybe their solutions can be used with lbzip2.
I had tried to compile it on MinGW, but it didn't work out because of signals
MinGW has only a small amount of signals
those are missing: I had defined them at the bottom of common.h , not sure what is the effect of this.
define SIGUSR1 26
define SIGUSR2 27
define SIGXFSZ 28
ideas for signals alternative: http://www.perlmonks.org/?node_id=1022364 https://social.msdn.microsoft.com/Forums/vstudio/en-US/8d128695-1727-434b-9fd1-7b74b2bf25ea/need-a-better-way-for-inter-thread-communication-?forum=vcgeneral
also had an error:
signals.c:78:20: error: storage size of 'act' isn't known struct sigaction act;
migw's signal.h
pthread_signal.h
just to give some sense about the errors: the last one i did not knew how to solve .