Stream: git-wasmtime

Topic: wasmtime / issue #7569 wasi: fs time precision option


view this post on Zulip Wasmtime GitHub notifications bot (Nov 22 2023 at 20:34):

guybedford edited a comment on issue #7569:

@alexcrichton apologies for the confusion, I made an invalid assumption that the u64 mtime value was in units of 100 nanoseconds due to a misreading of the docs, Node.js instead has 1us accuracy.

I've changed the configuration option name to FS_TIME_PRECISION.

I also don't understand why Node is testing equality using division. Shouldn't the exact values be equal in Node? For example if Node reports a timestamp is N and it's updated to N+200us, then shouldn't the resulting timestamp afterwards be exactly N+200us?

Because Node.js rounds to microseconds, if we set a timestamp N, the timestamp that actually gets set is a Node.js-rounded N.

The other axis is a fine-grained update of time.

For now I've treated both of these axes the same - the fs time precision. Where the unit of time we update is twice the precision, and the unit of time we check for is equality under that same precision. This makes sense I think because we are effectively observing this implementation-defined rounding function.

Ready for review, further feedback welcome.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 22 2023 at 22:09):

guybedford commented on issue #7569:

Assuming that the system is only reporting timestamps with rounded precision already, this means that all timestamps in play should all be appropriately rounded, right?

Good point, yes this is the issue - Node.js provides the ability to read times as BigInt values, but not to set them as BigInt values. I've posted a Node.js feature request for this in https://github.com/nodejs/node/issues/50859.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 22 2023 at 22:48):

alexcrichton commented on issue #7569:

Aha! Ok that makes a lot more sense now. So Node is reporting nanosecond-granularity but only supports setting at the microsecond-granularity?

view this post on Zulip Wasmtime GitHub notifications bot (Nov 22 2023 at 23:26):

guybedford commented on issue #7569:

So Node is reporting nanosecond-granularity but only supports setting at the microsecond-granularity?

Yes, that's what I'm seeing. They only support IEEE-754 values in seconds, which would only store 24 bits of precision, so I think this is actually due to floating point arithmetic rounding, but haven't verified that's definitely the reason.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 22 2023 at 23:28):

guybedford edited a comment on issue #7569:

So Node is reporting nanosecond-granularity but only supports setting at the microsecond-granularity?

Yes, that's what I'm seeing. They only support IEEE-754 values in seconds, which would only store 24 digits of precision, so I think this is actually due to floating point arithmetic rounding, but haven't verified that's definitely the reason.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 22 2023 at 23:28):

guybedford edited a comment on issue #7569:

So Node is reporting nanosecond-granularity but only supports setting at the microsecond-granularity?

Yes, that's what I'm seeing. They only support IEEE-754 values in seconds, which would only store 24 precision digits, so I think this is actually due to floating point arithmetic rounding, but haven't verified that's definitely the reason.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 23 2023 at 03:35):

alexcrichton commented on issue #7569:

Ah I could definitely imagine that once floats are involved precision flies out the window. Thanks for putting up with my questions!

view this post on Zulip Wasmtime GitHub notifications bot (Nov 23 2023 at 18:33):

guybedford commented on issue #7569:

CI was failing due to the use of an experimental feature. I've simplified the check which should pass CI now.


Last updated: Dec 23 2024 at 12:05 UTC