Skip to content
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

Windows Compatibility Fixes #1 #2535

Merged
merged 14 commits into from
Feb 9, 2019
Merged

Conversation

yeastplume
Copy link
Member

@yeastplume yeastplume commented Feb 6, 2019

Meta Issue: #2525

After this PR, Grin should compile, run and sync on windows (with remaining problems, see #2525 for instructions and remaining issues). In particular, this:

  • Updates croaring-rs from 0.3 to 0.3.8
  • Remove daemonize and grin server stop|start commands
  • Update inclusion of cursive to be platform conditional, change terminal backend for Windows to pancurses
  • Updates to PMMR (particularly file rewind) to allow for explicit dropping of file handles. Required due to stricter locking on windows
  • Modifications to store and wallet tests (which also need to explicitly drop file handles in many cases)
  • Temporarily reduce initial LMDB file storage on windows (more complete solution needed, see (GrinWin) - Windows 10 Support Meta-Issue #2525)
  • Add functions to explicitly drop underlying file handles in TxHashSet. Not doing so was preventing fast-sync archives from unzipping.

These changes definitely need to be reviewed and tested to ensure they don't break anything on linux

hash_file: DataFile<Hash>,
data_file: DataFile<T::E>,
hash_file: Option<DataFile<Hash>>,
data_file: Option<DataFile<T::E>>,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Options so they can be dropped before renaming operations

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be cleaner by pushing this down to DataFile and AppendOnlyFile.

.read(true)
.create(true)
.append(true)
.open(&self.path)?;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

File permissions for set_len on windows need to be as set here or it fails. Hence the drop and reopen with original permissions after the set_len.

Copy link
Contributor

@ignopeverell ignopeverell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overeall looking good but as you're already doing a fair amount of handling in AppendOnlyFile, it looks like a lot of the recreating could be pushed down there as well, avoiding the multiple Option hassle.


//TODO: This
#[cfg(target_os = "windows")]
fn daemonize(config: servers::ServerConfig) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been pondering removing the use of daemonize and start/stop altogether. Unixes provide plenty of ways to do this and there are a couple ways on Windows as well. People are likely to want to do it in all sorts of different ways as well.

hash_file: DataFile<Hash>,
data_file: DataFile<T::E>,
hash_file: Option<DataFile<Hash>>,
data_file: Option<DataFile<T::E>>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be cleaner by pushing this down to DataFile and AppendOnlyFile.

@@ -334,20 +349,24 @@ impl<T: PMMRable> PMMRBackend<T> {
}
self.prune_list.flush()?;
}

// drop hash file, or windows will still have a lock on it and won't allow the rename
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If pushed down, then the whole remove, rename and reallocate can be encapsulated in some reopen operation in AppendOnlyFile?

//TODO: This is temporary to support (beta) windows support
//Windows allocates the entire file at once, so this needs to
//be changed to allocate as little as possible and increase as needed
#[cfg(target_os = "windows")]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add cfg!(target_os = "ios") here as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather just keep this PR to windows issues for now, and this is just temporary. The real fix shouldn't involve OS specific code, but it should allocate the file minimally and increase it as necessary.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, got it! let me know if I can help somehow with this upcoming fix!

@yeastplume
Copy link
Member Author

@ignopeverell Thanks, cleaned that up and encapsulated the file rename/replace. However, needs slightly more review given that I had to add functionality to drop underlying PMMR files from the txhashset during fast sync archive unzip. Marked above.

{
let mut txhashset_ref = self.txhashset.write();
// Drop file handles in underlying txhashset
txhashset_ref.release_backend_files();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to work, would just like a bit of reassurance that this isn't going to have any odd side effects.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I can think of, seems fair.

@yeastplume
Copy link
Member Author

Also, removed Daemonize altogether, think I agree it's far easier to use external commands to run something as a service in most cases

Copy link
Contributor

@ignopeverell ignopeverell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice, all looking good to me!

{
let mut txhashset_ref = self.txhashset.write();
// Drop file handles in underlying txhashset
txhashset_ref.release_backend_files();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I can think of, seems fair.

@ignopeverell ignopeverell added this to the 1.1.0 milestone Feb 9, 2019
@yeastplume yeastplume merged commit 15c7a27 into mimblewimble:master Feb 9, 2019
yeastplume pushed a commit that referenced this pull request Feb 13, 2019
* - Add backwards compatability
- Add hex serialization

* rustfmt

* rustfmt

* Windows Compatibility Fixes #1 (#2535)

* initial changes for windows build and unit/integration tests

* rustfmt

* wallet+store tests

* rustfmt

* fix linux daemonize

* better encapsulate file rename

* rustfmt

* remove daemonize commands

* rustfmt

* remove server start/stop commands

* add ability to drop pmmr backend files explicitly for txhashset unzip

* rustfmt

* fix pmmr tests

* rustfmt

* Windows TUI Fix (#2555)

* switch pancurses backend to win32

* revert changes to restore test

* compatibility fix + debug messages

* rustfmt

* Add content disposition for OK responses  (#2545)

* Testing http send and fixing accordingly

* add repost method into wallet owner api (#2553)

* add repost method into wallet owner api

* rustfmt

* Add ability to compare selection strategies (#2516)

Before tx creation user can estimate fee and locked amount
with different selection strategies by providing `-e` flag for
`wallet send` command.
@yeastplume yeastplume deleted the windows_1 branch March 4, 2019 10:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants