<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>I don't think it's possible to do that automatically, since
jextract can not detect whether a function sets the last error
from the header file (as far as I know that fact is only
documented).</p>
<p>Though, I think we could add a new command line flag to list the
functions that need the last error saved. Maybe the syntax of
--include-function could be extended for that.</p>
<p>Jorn<br>
</p>
<div class="moz-cite-prefix">On 10/09/2022 09:09, Manuel
Bleichenbacher wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA7F5jL_Jm_P+5k7CxsSckGZxdKHwx8au+Va3Tk7dUe2G0BsaQ@mail.gmail.com">
<div dir="ltr">I'm happy to see that discussion about this issue
continues. It's the only issue in project Panama that's really
holding my work (<a href="https://github.com/manuelbl/JavaDoesUSB" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/manuelbl/JavaDoesUSB</a>)
back. For all other issues, there's a workaround.
<div><br>
</div>
<div>You are probably far more familiar with the internals of
the Java VM than I am. But I can confirm that it's not a
debugger only issue. The last error is overwritten more
frequently while debugging, but it occurs without the debugger
as well.</div>
<div><br>
</div>
<div>I don't share the fear that more errno-like things will
come along. The problem can only occur for errno-like things
that are used by both the Java VM and by third-party software.
It cannot occur for some random third-party library. So unless
the Java VM starts using a new library with this ancient
pattern, it's a non-issue.</div>
<div><br>
</div>
<div>The proposed design looks good to me and aligned with the
design principles I've seen so far. It would certainly work my
USB library.</div>
<div><br>
</div>
<div>The only open issue I see is with jextract. Would it be
possible to instruct jextract to generate code this extra
action, or would this only work with manually written binding
code?</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Sep 10, 2022 at 1:50
AM John Rose <<a href="mailto:john.r.rose@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">john.r.rose@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:sans-serif">
<div style="white-space:normal">
<p dir="auto">On 12 Aug 2022, at 7:50, Maurizio
Cimadamore wrote:</p>
</div>
<div style="white-space:normal">
<blockquote style="margin:0px 0px
5px;padding-left:5px;border-left-width:2px;border-left-style:solid;border-left-color:rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">On 12/08/2022 15:43, Pedro Lamarão
wrote:</p>
<blockquote style="margin:0px 0px
5px;padding-left:5px;border-left-width:2px;border-left-style:solid;border-left-color:rgb(153,153,153);color:rgb(153,153,153)">
<p dir="auto">… This would be a blocker for all
applications of Windows API functions via panama.
<br>
Windows Sockets has a similar mechanism called
WSAGetLastError.</p>
</blockquote>
<p dir="auto">And JNI - I doubt there's anything
Panama specific here (unless proven otherwise).</p>
<p dir="auto">So that it's clear - it's not that
GetLastError fails in general. It fails when a
debugger is attached. As I explained, this could be
due to _which_ debugger is attached, or some
existing issue (predating Panama) in the way
jdb/JPDA deal with some Windows system calls.</p>
<p dir="auto">Maurizio</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">Besides debugger interactions, I would
worry about the VM itself doing some housekeeping
functions between the two Panama calls. For example,
if the first call ends at a safepoint request, the
thread can go into safepoint-mode, and that is rather
open-ended in its effects. If those effect include
something as simple as a storage allocation (malloc)
then the last-error in that thread might be reset.
It’s hard to exclude such things unless we design in a
real transaction of some sort which excludes all
artifacts like safepoints or debugger operations.</p>
<p dir="auto">That’s why I nodded along when you,
Maurizio, suggested a combinator for bundling together
two downcalls into a single region. I see Jorn’s
objection; it is in some sense a good design but it is
very expensive to maintain, as a general-purpose
facility. Imagine writing the regression tests…</p>
<p dir="auto">But, something like that transaction is
clearly needed, though, for the specific operation of
getting the last error. (Somebody is eventually going
to come along with a second errno-like thing as well,
which is a scary thought…) So we need, at least, a
bespoke transactional feature for downcalls that saves
the errno somewhere, no matter what. I like Vladimir’s
suggestion for poking it down an extra argument.</p>
<p dir="auto">Here’s a slightly-general design for such
a thing that is slightly future-proof, for the sake of
brainstorming:</p>
<ul>
<li>Panama supplies a limited number of “extra
actions” that can be attached to any downcall.</li>
<li>The only action defined initially gets a machine
word which encodes some sort of error state visible
after a downcall.</li>
<li>Adding more actions, and user control over them,
is left for the future.</li>
<li>An extra action can have a return value. If you
attach it to a downcall, you can capture that return
value by adding a trailing (appendix) parameter, for
a copy-out. Or, perhaps, you can route it directly,
replacing the main return value of the downcall.</li>
</ul>
<p dir="auto">This picks up on the suggestion that
downcalls can be configured to capture this extra
information. And it generalizes the “save-error”
feature.</p>
<p dir="auto">Finally, it makes the “ignore-error”
feature unnecessary; that is a good thing, since if
you have to opt into ignoring errors, it means that
somebody is by default saving them for you. That is
likely to turn into an overhead on every call,
regardless of whether the saved data is useful or not.</p>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>