<div dir="ltr"><div dir="ltr">Em seg., 15 de ago. de 2022 às 18:54, David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> escreveu:<br></div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> What matters is that the code below observes the status of write.<br>
> <br>
> write(...)<br>
> log(last-error())<br>
> <br>
> If there is some code running somewhere with the power of affecting <br>
> last-error on this thread, that code must be very careful to preserve it.<br>
<br>
Yet you say it is not a library's responsibility to do that? How is the <br>
library less responsible than a call to class-loading, or running an <br>
event handler, or entering the debugger?<br></blockquote><div><br></div><div>I don't understand what you mean by library in this instance.</div><div>There are three calls, one to write, next to last-error, finally to log;</div><div>the application is doing nothing else in this snippet.</div><div>The application is correct exactly because there is no call into the system,</div><div>directly or indirectly, between calling write and calling last-error.</div><div>log cannot clobber last-error, since log is called after, not before.<br></div><div><br></div><div>If by library you mean the foreign function interface library itself,</div><div>then we enter the case below: such code must never clobber last-error,</div><div>and must always preserve it in case of calling into the system.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> It has been supposed that the OP's debugger is doing I/O from inside the <br>
> application's thread;<br>
> if that is the case, then this debugger must do something like <br>
> PreserveLastError.<br>
<br>
Even if it did that would not be sufficient as you would need a general <br>
solution for preserving it between the user function that sets it, and <br>
the user function that wants to read it. The handler for a method exit <br>
event could also overwrite last-error before the debugger gets a chance <br>
to preserve anything. I don't know if the way the debugger operates even <br>
allows for conceptually saving and restoring the last-error across <br>
debugger "entry points".<br></blockquote><div><br></div><div>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.</div><div>This is true for any such code, anything which may clobber last-error in the application's thread.</div><div>This is a universal problem in "framework" style code.<br></div><div>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.</div><div>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.</div><div>People in need of FFI would be required to distribute a companion native library, greatly diminishing the benefits of FFI over JNI.</div><div><br></div><div>--<br></div></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>