Compile bug, unresolved import `crate::sys`

1

Hello,
I'm trying to compile a project against target wasm32-wasi.
But I'm getting errors on the crate::sys.
I know wasm currently doesn't allow to read/write on files but I'm not using wasm alone. The target build its on wasi.

Here its my command :
cargo build --target=wasm32-wasi --release

Using:
rustc 1.58.0 (02072b482 2022-01-11)

Error:
error[E0432]: unresolved importcrate::sys --> C:\Users\Owner\.cargo\registry\src\github.com-1ecc6299db9ec823\fslock-0.2.1\src\string.rs:3:12 | 3 | use crate::sys::{Error, OsStr, OsString}; | ^^^ could not findsysin the crate root

1 Like
2

File IO is irrelevant. It says your lib.rs or main.rs doesn't have pub mod sys; or pub use xxx as sys; etc.

1 Like
3

Not their one. The error is in fslock, and it indeed exports sys module only on windows and unix. This might be worth a PR to the fslock, if it's possible to implement this functionality in wasi.

2 Likes
4

I guess @Cerber-Ursi is right.
Acording to following code
https://github.com/koute/stdweb/blob/master/src/webcore/ffi/mod.rs

I guess fslock has to implement target_arch = "wasm32", target_os = "unknown" mod for wasm like stdweb does.

5

WASI doesn't have filesystem locks: WASI/wasi_unstable.witx at main · WebAssembly/WASI · GitHub

It is effectively impossible to implement file locks in a way portable across operating systems. On unix you have fcntl and flock both of which are advisory (meaning all programs need to opt-in to using them) locks. Fcntl are effectively impossible to use correctly when using libraries as locking a file twice from the same program causes a single lock to be taken. Closing any fd for the respective file will unlock this single lock. Flock isn't as portable as fcntl however. See also Cross-platform library for file locking?

2 Likes
6

Thanks @bjorn3 for your clear answer.
I have read the link you posted. However can I ask you what we can use as alternative to fslock ? If there is any ?

7

The best you can do I think is to create a "lock file" when locking and removing it when unlocking. You can then act as if the file is locked if the lock file exists. This requires manually deleting the hidden file on crashes though. In addition you can't wait for the file to be unlocked in any other way that checking for the "lock file" in a loop with a small delay after every check.

1 Like
8

Can't you use inotify instead of a busy loop?

One strategy I've seen programs use is to write their PID into the lockfile.

Then when you try to take the lock you can check whether that process is still alive or prompt the user with an error like "refusing to start because /path/to/lockfile exists. Note: the owning process (pid 1234) is no longer running, did it crash?". Then the user can double-check the program isn't still running or manually delete the lockfile.

Process IDs can obviously be reused so this isn't foolproof, but it's a simple way to aid troubleshooting and could be extended for better accuracy (e.g. by checking if that process is running an instance of your program).

9

That again is not portable. It even worse in some ways as there is a global limit on the amount of active inotify watchers at the same time. This limit applies to all users combined and is 8192 (for amount of watches, 128 for the amount of instances) by default on my system. You can look at /proc/sys/fs/inotify/ to find the limits on your own system.

Wasi doesn't have pid's. In fact it doesn't even know of the concept of "process" by default. Also a single wasi runtime (and thus single process) may run multiple wasi modules which would each need their own pid.

1 Like
10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.