GetLastError() (with and without debugger)

[Pedro Lamarão]

Em seg., 15 de ago. de 2022 às 18:54, David Holmes <david.holmes at oracle.com>
escreveu:

> What matters is that the code below observes the status of write.
> >
> > write(...)
> > log(last-error())
> >
> > If there is some code running somewhere with the power of affecting
> > last-error on this thread, that code must be very careful to preserve it.
>
> Yet you say it is not a library's responsibility to do that? How is the
> library less responsible than a call to class-loading, or running an
> event handler, or entering the debugger?
>

I don't understand what you mean by library in this instance.
There are three calls, one to write, next to last-error, finally to log;
the application is doing nothing else in this snippet.
The application is correct exactly because there is no call into the system,
directly or indirectly, between calling write and calling last-error.
log cannot clobber last-error, since log is called after, not before.

If by library you mean the foreign function interface library itself,
then we enter the case below: such code must never clobber last-error,
and must always preserve it in case of calling into the system.


> > It has been supposed that the OP's debugger is doing I/O from inside the
> > application's thread;
> > if that is the case, then this debugger must do something like
> > PreserveLastError.
>
> Even if it did that would not be sufficient as you would need a general
> solution for preserving it between the user function that sets it, and
> the user function that wants to read it. The handler for a method exit
> event could also overwrite last-error before the debugger gets a chance
> to preserve anything. I don't know if the way the debugger operates even
> allows for conceptually saving and restoring the last-error across
> debugger "entry points".
>

If the handler of a method exit event calls into the system from an
application's thread, directly or indirectly, then it must take care of
preserving last-error.
This is true for any such code, anything which may clobber last-error in
the application's thread.
This is a universal problem in "framework" style code.
Unless this is addressed on "framework" X, it will be effectively
impossible to program X with the new FFI to call into the system correctly.
That may be acceptable for some X; it may document itself as clobbering
last-error in this or that or any condition, of being FFI unfriendly.
People in need of FFI would be required to distribute a companion native
library, greatly diminishing the benefits of FFI over JNI.

--
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220815/5f6e0633/attachment-0001.htm>