<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">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">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"><u></u>


<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>