Matt Corallo [Thu, 30 Jun 2022 04:19:13 +0000 (04:19 +0000)]
[TS] Split C -> JS function calls based on u32/u64 parameters/return
We were calling all C -> JS functions with u32 parameters and
return types. This is fine for all of our pointers, as well as any
smaller types - u32 always gets mapped to a JavaScript `number`, so
its all consistent.
However, for u64 parameters/returns, we map the values to
JavaScript `bigint`s, which are not compatible with `numbers`, and
the correct type is checked at the FFI when returning or when users
ultimately try to use a passed `bigint` as if it were a `number`.
Thus, we have to split the `js_invoke_function` family by the
parameters and return values, using `u` for u32s and `b` for u64s
to do so.
Matt Corallo [Mon, 27 Jun 2022 19:36:44 +0000 (19:36 +0000)]
[Java] Update batteries and tests to 0.0.108
This is mostly pretty obvious changes to keep up with the latest
API, though it also includes a change to make `PeerTest` work
correctly in a world where `PeerManager` supports multithreaded
parallel access.
Matt Corallo [Mon, 27 Jun 2022 18:20:45 +0000 (18:20 +0000)]
Use fully-qualified types more often in conversions
This ensures to-human conversions still work correctly inside
enums where there is an enum variant named identically to the type
which is being converted to (eg in the new `GraphSyncError` enum).
Matt Corallo [Fri, 15 Apr 2022 18:50:15 +0000 (18:50 +0000)]
[Java] Correct trivial race condition in HumanObjectPeerTest
On my (very slow) old armv7 device, HumanObjectPeerTest can fail as
`maybe_exchange_peer_messages` will set `ran = false` *after* a
message is added to the runqueue, but before it runs, then when we
call `process_events` there will be no events to process, then
before we get into the `runqueue` `synchronized` block the message
will be delivered, causing us to think we're done, even though
there are now events pending. Because going around the loop twice
is free, we should just not set `ran` to false at the top of
`maybe_exchange_peer_messages`.
Matt Corallo [Fri, 15 Apr 2022 16:11:46 +0000 (16:11 +0000)]
Convert primitives before passing to host language
This resolves an issue where we map unsigned primitives to their
signed variants, and occasionally pass the unsigned variant (which
is outside the bounds of the signed variant) to the host language.
In Java this can cause a panic as the VM sees an int outside the
range of a short (for example with network ports).
Matt Corallo [Wed, 23 Mar 2022 18:44:04 +0000 (18:44 +0000)]
Don't assume from-var conversion in opaque ret conv
When we do a ret-conv of an opaque struct, don't assume that the
variable as-parsed exists, instead use the variable that's being
created in the ret-conv string if we need to clone.
Matt Corallo [Thu, 3 Mar 2022 02:32:15 +0000 (02:32 +0000)]
[Java] Add a reachabilityFence on underlying trait impl calls
Because the implementation instance is implicitly held as a
reference in the `held` field, it seems unlikely this could ever
matter, hwoever, in the simplified implementation in `PeerTest`
(where there is no Human instance to hold a reference to the
underlying bindings instance), we do see the implementation being
free'd while its still in use. Thus, to ensure we can't hit any
such issue in the future, we add one in normal human objects as
well.
Matt Corallo [Thu, 27 Jan 2022 18:39:52 +0000 (18:39 +0000)]
[Java] More carefully ensure sockets are closed in `NioPeerHandler`
There is no indication that the sockets are leaking in the handling
loop, but its good to be careful and ensure we always both close
the SocketChannel and cancel the key registration.
During connection, however, it appears we may leak a SocketChannel
if the connection times out, leaking a file descriptor at least
until the GC kicks in and cleans up after us. Here we are more
careful.
Matt Corallo [Mon, 17 Jan 2022 02:54:11 +0000 (02:54 +0000)]
Use uintptr_t in generic conversion when we're talking about pointers
This may make it harder to support 32-bit Java platforms in the
future if we have a reason to do so, but that seems unlikely and
its possible we can simply redefine the type.
Matt Corallo [Mon, 17 Jan 2022 02:50:23 +0000 (02:50 +0000)]
Use intptr_t in C when talking about a pointer.
This fixes a bug in TS where we'd return an int64_t when we intended
to return a pointer, confusing JavaScript as to why it has a bigint
instead of a number.
This may make it harder to support 32-bit Java platforms in the
future if we have a reason to do so, but that seems unlikely and
its possible we can simply redefine the type.
projects / ldk-java / log