I've been thinking a bit about this for a while. The new interface to
the run-time system uses something like yje FFI calling process but
there are two different forms. The simpler, faster form can be used if
the C++ code does not need to allocate memory or raise an exception.
Otherwise the more general form has to be used. Many of the run-time
calls currently raise exceptions if there is an error so have to use the
general form. Adding the ability to test the error result would allow
the exception to be raised in ML code.
Just to explain what I've done for those who haven't looked at the
commits: there is now an extra sub-structure in the Foreign structure,
Error. This has signature:
structure Error:
sig
val getLastError: unit -> SysWord.word
val setLastError: SysWord.word -> unit
type syserror = OS.syserror
val fromWord: SysWord.word -> syserror
val toWord: syserror -> SysWord.word
end
getLastError returns the value of errno on Unix/Cygwin and GetLastError
in Windows. setLastError sets errno or calls SetLastError. fromWord
and toWord are the same as Posix.Error.fromWord/toWord but I've provided
them because that structure isn't present in Windows.
David
On 07/12/2016 07:29, Kostirya wrote:
Hello, David.
I saw your PolyML last commits on github.
I'm impressed! You've considered all my remarks!
Many thanks!
P.S.
Foreign.Error.getLastError will be very useful for
https://github.com/kni/sml-iconv :-)
2016-11-15 18:35 GMT+02:00 David Matthews <david.matth...@prolingua.co.uk>:
I'm still thinking about this. It would certainly be useful to get the
error result: errno in Unix and GetLastError and possibly also errno in
Windows. It don't see a way to specify this as a return type in the FFI
calls.
The main problem is that there can be invisible calls into the run-time
system as a result of either heap exhaustion or stack overflow. As a first
step perhaps the error state should be saved explicitly across these so it
doesn't change under the feet of the application.
David
On 13/11/2016 11:49, Florian Weimer wrote:
* David Matthews:
The difficulty with getting errno in this way is that by the time you
get it it may have changed from the value it had. Any calls to the
run-time system may involve a system call that could affect it.
Would it make sense to use a special return type which instructs
PolyML to obtain the errno value at the time of return? This would
address the synchronization issue.
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
