GetLastError() (with and without debugger)

[John Rose]

On 12 Aug 2022, at 7:50, Maurizio Cimadamore wrote:

> On 12/08/2022 15:43, Pedro Lamarão wrote:
>> … This would be a blocker for all applications of Windows API 
>> functions via panama.
>> Windows Sockets has a similar mechanism called WSAGetLastError.
>
> And JNI - I doubt there's anything Panama specific here (unless proven 
> otherwise).
>
> 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.
>
> Maurizio

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.

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…

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.

Here’s a slightly-general design for such a thing that is slightly 
future-proof, for the sake of brainstorming:

  - Panama supplies a limited number of “extra actions” that can be 
attached to any downcall.
  - The only action defined initially gets a machine word which encodes 
some sort of error state visible after a downcall.
  - Adding more actions, and user control over them, is left for the 
future.
  - 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.

This picks up on the suggestion that downcalls can be configured to 
capture this extra information.  And it generalizes the “save-error” 
feature.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220909/dab09226/attachment.htm>