On Thu, 27 Mar 2025 06:27:44 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>> Larry Cable has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c >> >> Co-authored-by: David Holmes >> <62092539+dholmes-...@users.noreply.github.com> >> - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c >> >> Co-authored-by: David Holmes >> <62092539+dholmes-...@users.noreply.github.com> >> - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c >> >> Co-authored-by: David Holmes >> <62092539+dholmes-...@users.noreply.github.com> > > src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 157: > >> 155: snprintf(msg, sizeof(msg), "pid: %d, state is not ready to >> participate in attach handshake!", (int)pid); >> 156: >> 157: JNU_ThrowByName(env, >> "com/sun/tools/attach/AttachNotSupportedException", msg); > > I am not too familiar with JNI. Would it be cleaner/beneficial if this native > method just returned `JNI_TRUE`/`JNI_FALSE` to indicate whether or not the > `SIGQUIT` was sent and then in the Java code side, handle the > `throwIfNotReady` part and create and throw the exception if this function > returned `JNI_FALSE` and `throwIfNotReady` was `true`? > Would there be any benefit of doing that in the Java side instead of here? it would be different not necessarily better and this is the same pattern as is used for the pre-existing Linux imp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2017663410
