<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 12 Aug 2022, at 7:50, Maurizio Cimadamore wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">On 12/08/2022 15:43, Pedro Lamarão wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><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 class="markdown" 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></body>
</html>