John Meacham wrote: > I was thinking about this too but had a different idea, an alternate > calling form which grabbed the result of errno and returned it to > haskell land. that way the cost of geting errno is only paid for those > foreign imports which care about it. like > > foreign import ccall_errno "unistd.h chdir" :: Ptr CChar -> IO (CInt,CInt) > > where the second CInt returned will be the value of errno after the call > to chdir.
John's first suggested alternative above seems very appealing to me, as it seems neatly to fix the fundamental design flaw in `errno`: that determining the success/failure of a system call is separated from the call itself. I'm surprised more sentiment in its favor has not shown up. What are the disadvantages of such a solution? > another solution is to do everything in C wrappers which return errno as > well as the return value. > > another is some sort of blocking function which blocks context switching > within the same OS thread temporarily.. > > or your idea below. just thought I'd throw some alternate ideas into the > mix. I am not a fan of having to stow errno for every ffi call.. > John > > On Thu, Jul 24, 2003 at 11:48:02PM +0200, Wolfgang Thaller wrote: > > First, the "bug" part: > > > > None of the libraries that use errno are compatible with concurrency. > > When a (lightweight) thread-switch occurs between the call to some > > foreign function and the corresponding call to > > Foreign.C.Error.getErrno, we have a problem: > > > > a) the RTS trashes the value of errno > > b) another Haskell thread might call a function that sets errno > > c) on most platforms, errno is thread-local state, with all the > > consequences that has for the threaded RTS (bound threads required....) > > > > Now, the "ffi" part: > > > > b) and c) could be solved by using bound threads, but that's probably > > too inefficient for something that's used as frequently as errno. > > Bound threads wouldn't solve a). > > > > I therefore propose that we make the RTS save & restore the value of > > errno in the TSO, thus making errno "Haskell-Thread-Local-State", and > > solving all of the above problems. > > I also propose adding a note to the FFI spec (or the bound threads > > document, I'm not sure which is the right place) that says that > > implementations have to make sure that "Errno" is local to each > > *Haskell* thread. -- Dean _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
