Re: The Errno Story

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