April 2006 - Haskell-prime

RE: Exceptions
by Simon Marlow 07 Apr '06

07 Apr '06

John, have you seen this? http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Extensible Exceptions Cheers, Simon On 07 April 2006 15:34, John Goerzen wrote: > Hello, > > One thing that bugs me about Haskell is that exceptions are not > extensible. > > I don't know how to craft a good solution, but perhaps if I explain > the problem well, someone would come up with one. > > In a language such as Python or Java, and exception is an object. > > Let's consider Python for a quick example. Python has an IOError > exception. So if I want to write a handler that deals with IOErrors, > that's easy enough. > > Now maybe I want to do something like report socket errors specially. > I could define a SocketError class that subclasses IOError. I could > take this further, and define a URLError that subclasses SocketError. > > Now the beauty of it is that I can: > > * Have a handler that catches URLErrors only and does nothing special > with SocketErrors or IOErrors. > > * Have a handler -- perhaps not even mine -- that catches and works > with IOErrors. Since SocketError and URLError are descendants of > IOError, that handler will *automatically* work if I raise a > SocketError or a URLError. > > I can see no such mechanism in Haskell. Haskell's I/O exceptions > have a certain defined set of errors that they can report, and I > can't subclass them and make them more specific for my purposes if I > want. Ditto for all the others. > > The Dynamic exception support is necessary and good to have, but it > also under-documented and can be complex. And of course, they still > suffer from the same lack of extensibility > > Are there any suggestions on how we might improve this situation in > Haskell? > > -- John

3 2

Re: deeqSeq proposal
by Rene de Visser 07 Apr '06

07 Apr '06

Hello, As deepSeq has a non local effect, I think it requires a non-local source transformation to implement it. One option would be for the compiler to create a second deepSeq version of every function definition. e.g. If the user defines a function f f x = g h x then the compile creates an additional function !!f !!f x = temp `seq` temp where temp = !!g !!h x which uses the compiler generated functions !!g and !!h. It looks like library writers are increasingly doing this manually. Creating a strict and non strict version of a number of the functions provided. This would automate that. Rene.

2 1

RE: asynchronous exceptions
by Simon Marlow 07 Apr '06

07 Apr '06

On 07 April 2006 00:36, Marcin 'Qrczak' Kowalczyk wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> I agree with your assessment of the problems with interruptible >> operations in GHC: that it is impossible to completely block async >> exceptions across a computation. We could certainly add a way to >> do this. Is that the substance of your objection to GHC's async >> exception mechanism? > > Regarding interruptible operations, this and one more thing that I > haven't written there: > > The fact that some function uses an interruptible operation internally > is a visible aspect of its behavior, both in GHC design and in mine. I don't consider this to be a problem. Every API call you make has the potential to throw exceptions, and since we don't usually go to the trouble of documenting every exception that every library function can raise, the caller always has to be prepared to handle arbitrary exceptions thrown by calls to library functions. Asynchronous exceptions thrown by interruptible operations just fall into this category. BTW, I just realised a better way to express block. If block is supposed to count nesting, then we have a problem that you can still unblock exceptions even within a block by using sufficient number of unblocks, so the right way is to give block this type: block :: ((IO b -> IO b) -> IO a) -> IO a you use it like this: block $ \restore -> (do x <- takeMVar m restore (...) `catch` \e -> ...) so the only way to unblock is to restore the state of an enclosing block. Returning the restore function and using it outside the block isn't dangerous, so we don't have to play any quantified type games to prevent that. Cheers, Simon

2 1

RE: Signals + minimal proposal (was Re: asynchronous exceptions)
by Simon Marlow 07 Apr '06

07 Apr '06

On 06 April 2006 23:20, John Meacham wrote: > == on exit == > > implementations also provide an onExit functionality, for registering > handlers that can be run when the program exits, as this is the most > common use of signals as exceptions, to clean up after oneself. > > -- | temporarily register an exit handler for the duration of the > action argument withExitHandler :: IO () -> IO a -> IO a > withExitHandler = .... > > -- | register a handler to be run on exiting the program > onExit :: IO () -> IO () > onExit = .... > > -- | block exiting during this call for critical sections. > blockExit :: IO a -> IO a > blockExit = ... > > although thees are less powerful than exceptions in that you can only > catch a single event, "exit" they are more powerful in the sense that > the exception handlers are global, so when you register an exit > handler > it happens no matter what thread is in scope. > > > in addition, an exit_ routine should be added that bypasses the exit > handlers, quiting the program immediatly. I'm not sure I like using exit handlers instead of real exceptions. If the exit handler needs access to some shared mutable state, then it must be sure that the state is not locked when it gets invoked, so all access to the shared state must be protected by blockExit. So all our MVar abstractions will need to use blockExit - but wait, we already use Control.Exception.block in GHC for very similar reasons. And what's more, blockExit suffers from the same problems that we solved with block and interruptible operations: you need to be interruptible while waiting for something (like an MVar), but once it is acquired, the thread should not be interruptible until it has established an exception handler to release the MVar. Exceptions are the right way to handle releasing resources, and they are the right way to register cleanup actions. Therefore I believe exceptions are the right way to handle cleaning up on exit, too. Since async exceptions are no problem to implement in a coop system, shouldn't we use them for exit too? Cheers, Simon

2 1

RE: Signals + minimal proposal (was Re: asynchronous exceptions)
by Simon Marlow 07 Apr '06

07 Apr '06

On 07 April 2006 13:24, David Roundy wrote: > The catch to this [no pun intended] > is that when the main thread exits all other threads are silently > terminated, without the chance to clean up... This is a mistake in GHC, I think. When someone calls exit, or when the main thread exits, all the other threads in the system should be send exceptions too. Cheers, Simon

1 0

RE: asynchronous exceptions (was: RE: Concurrency)
by Simon Marlow 07 Apr '06

07 Apr '06

On 05 April 2006 13:38, John Meacham wrote: > On Wed, Apr 05, 2006 at 07:47:08AM -0400, David Roundy wrote: >> For me, asynchronous exceptions are the primary reason to use >> concurrent Haskell. They're the only way I'm aware of to write a >> program that handles signals in Haskell, and it's be a real shame to >> leave Haskell' programs unable to handle signals--it means that any >> real-world programs that deal with locking or the like will need to >> use non-standard extensions. Unless you can come up with some other >> way to deal with signals. Having no chance to clean up when >> control-C is hit isn't an acceptable alternative, and neither is >> simply ignoring control-C and forcing users to run kill (and then >> once again get no chance to clean up!). > > I have been giving signals some thought, and resarching what other > languages do, and have a semi-proposal-maybe. We should be careful here: the Haskell standard has so far remained platform-independent, and I think it would be nice to keep it that way. I'm not proposing that we ignore signals, just that we should clearly delimit the platform-specific bits, perhaps by putting signal support into an addendum. > signals tend to be used for one of a couple purposes (some can fall > into multiple categories): > > signal a synchronous exceptional event - SIGFPE, SIGPIPE, SIGILL, > SIGSEGV > signal an asynchronous exceptional event - SIGINT, SIGHUP > (interactive) > inform the app of an event it might want to take note of - SIGALRM, > SIGCHLD, SIGWINCH, SIGHUP (daemon) > > I think it would make sense to have 3 mechanisms to cover these cases. > > signal a synchronous exceptional event > - raise a (possibly imprecise) exception on the thread that produced > the signal. GHC has no support for these right now. They're pretty tricky to handle, because the OS thread that caused the signal to be raised is stopped at some arbitrary instruction, and it would require some serious acrobatics to munge that OS thread into a state where it is possible to raise the (Haskell) exception. I do vaguely recall that people have achieved this in the past, in order to use page faults for write barriers, that sort of thing. SIGPIPE is possibly easier than the others. SIGFPE you can usually turn off in favour of "exceptional values" instead. > signal an asynchronous exceptional event > - the user should be able to choose the threads on which they wish to > catch these, those that need to clean up after themselves. > > inform the app of an event it might want to take note of > - these should run on their own thread, concurrently to all other > threads GHC directly support the latter version, and you can implement the former with a little extra code and a global variable. I think it would be nice to do as you suggest and provide a way to have the async signals turn directly into exceptions. One problem, though, is that because we can't interrupt a foreign call with an async exception, ^C can be rather unresponsive. Perhaps I should look into this and see whether it would be possible in GHC for a concurrent foreign call to be interruptible; it would involve terminating the foreign call somehow (pthread_cancel?) before raising the exception. We can't do this in a bound thread, however. Cheers, Simon

3 2

RE: Signals + minimal proposal (was Re: asynchronous exceptions)
by Simon Marlow 07 Apr '06

07 Apr '06

On 06 April 2006 23:20, John Meacham wrote: >> I'm not proposing that we ignore signals, just that we should clearly >> delimit the platform-specific bits, perhaps by putting signal support >> into an addendum. > > yeah, I was thinking a separate environment addendum should be in the > report, which takes behavior that is undefined in the language > standard, > and defines it for various platforms. it wouldn't extend the > functionality or scope of the standard, just define what couldn't be > defined in the standard. > > like the standard might say "the set of signals is undefined" while > the > UNIX addendum will say "the set of signals will include at least > SIGINT,SIGHUP,etc..." There's the question of whether ^C should look the same on both Windows and Unix. Windows doesn't have signals as such, but some things like ^C can be made to look like signals. We might consider specifying as part of the portable part of the API that there is at least an "interrupt" signal that corresponds to a user interrupt, and in the platform-specific part of the documentation we say what it actually maps to on each platform (SIGINT on Unix, CTRL_BREAK_EVENT on Windows, etc.). >> GHC has no support for these right now. They're pretty tricky to >> handle, because the OS thread that caused the signal to be raised is >> stopped at some arbitrary instruction, and it would require some >> serious acrobatics to munge that OS thread into a state where it is >> possible to raise the (Haskell) exception. I do vaguely recall that >> people have achieved this in the past, in order to use page faults >> for write barriers, that sort of thing. > > how does ghc handle things like divide by zero then? By checking before trying to divide :-) >>> signal an asynchronous exceptional event >>> - the user should be able to choose the threads on which they wish >>> to catch these, those that need to clean up after themselves. >>> >>> inform the app of an event it might want to take note of >>> - these should run on their own thread, concurrently to all other >>> threads >> >> GHC directly support the latter version, and you can implement the >> former with a little extra code and a global variable. I think it >> would be nice to do as you suggest and provide a way to have the >> async signals turn directly into exceptions. >> >> One problem, though, is that because we can't interrupt a foreign >> call with an async exception, ^C can be rather unresponsive. >> Perhaps I should look into this and see whether it would be possible >> in GHC for a concurrent foreign call to be interruptible; it would >> involve terminating the foreign call somehow (pthread_cancel?) >> before raising the exception. We can't do this in a bound thread, >> however. > > You should be able to handle the SIGINT imediatly no matter whether > foregin code is running if your handler is in its own thread right? Yes, but if the signal handler wants to send an exception to the main thread, as it often does, and the main thread is in a foreign call, ^C appears to not do anything. > just have the C signal handler write a byte to a pipe, your haskell > signal handler thread is in a > > repeatM $ do > readExactlyOneByte > signalHandler > > loop. Yes, this is exactly what GHC does. > = minimal proposal = > > I think a good minimal solution will be the following, it neatly > avoids > turning signals into exceptions, which may be problematic, but > provides > for the common cases of signal usages while being compatible with both > cooperative and SMP systems. > > == catching signals == > > implementations provide a way of catching signals such that the > handler > runs as if in its own thread. something like the following > > data SigInfo = ... > data HandlerType = SigOneShot | SigReset | SigIdempotent > > data SigAction = SigAction { > signalType :: HandlerType, > signalAction :: SigInfo -> IO () > } | SigDefault | SigIgnore | SigExit (SigInfo -> ExitStatus) > > installHandler :: Signal -> SigAction -> IO SigAction > installHandler = ... > > the action runs in its own thread. Yes, looks quite reasonable. > == on exit == I'll address this in a separate thread. Cheers, Simon

2 1

RE: asynchronous exceptions
by Simon Marlow 06 Apr '06

06 Apr '06

On 05 April 2006 16:46, Marcin 'Qrczak' Kowalczyk wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I'm not sure whether asynchronous exceptions should be in Haskell'. >> I don't feel entirely comfortable about the "interruptible >> operations" facet of the design, > > I designed that differently for my language. There is a distinct > "synchronous mode" where asynchronous exceptions are handled by > certain operations only, similarly to POSIX deferred mode of thread > cancellation. This allows to use blocking operations without being > interrupted. I think it's unnecessary to treat signals in the way you do - you're assuming that a signal interrupts the current thread and runs a new computation (the signal handler) on the same stack, completely blocking the interrupted thread until the signal handler completes. This is the wrong way to view signal handlers, IMO: they should run in completely separate threads (perhaps a higher priority thread, if possible). + you don't have to block signals just because you happen to be holding a mutex. Synchronisation with a signal handler is just synchronisation with another thread. + protecting the invariants of your mutable state from signal handlers is done using existing mechanisms for sharing mutable state with other threads + you can't just raise an exception from a signal handler, it has to be thrown to another thread. This raises the need for asynchronous exception handling and block/unblock, but that's simpler than signal handling. Basically, the whole situation is much simpler if signals don't *interrupt* threads. Of course I'm talking here about signals that are truly asynchronous. Synchronous signals should ideally just turn into exceptions directly (synchronous exceptions, of course). I agree with your assessment of the problems with interruptible operations in GHC: that it is impossible to completely block async exceptions across a computation. We could certainly add a way to do this. Is that the substance of your objection to GHC's async exception mechanism? I couldn't completely follow all the arguments from your paper (some example code would help!). Suppose we had block/unblock count scopes, as you suggested in your paper. We considered this at the time of the design, but rejected it because we wanted the property that unblock always unblocks exceptions. I must admit I can't see why this is an important property, now that I think about it; for modularity it seems you want the opposite. What about interruptible operations? We certainly want operations that are interruptible inside a block - that's the whole point. But we might also want to perform these same operations in a non-interruptible way, as you argued. So I propose also adding blockAll :: IO () -> IO () which is just like block, but it doesn't allow interruptible operations either. This gives us the full range of synchronous/asynchronous/blocked that pthreads has. Cheers, Simon

2 1

RE: deeqSeq proposal
by Simon Marlow 06 Apr '06

06 Apr '06

On 30 March 2006 23:12, Andy Gill wrote: > Implementation: > > deepSeq (RAW_CONS <is_deep_seq'd_bit> ... fields ) = > if <is_deep_seq'd_bit> == True > then return /* hey, we've already deepSeq'd this */ > else set <is_deep_seq'd_bit> to True. > deepSeq (field_1) > ... > deepSeq (field_n) > deepSEQ (REF/MVAR...) = return So deepSeq doesn't return _|_ when passed a cyclic structure? This is a bad idea, because it lets you distinguish cyclic structures from infinite ones. deepSeq has to behave like a function, regardless of its implementation. Cheers, Simon

7 11

FFI, safe vs unsafe
by Wolfgang Thaller 06 Apr '06

06 Apr '06

Hi everyone, Before adding non-concurrent, reentrant calls to the language standard, please take some time to think about what that means. If you have forkIO'ed multiple threads, things start to interact in strange ways. I think this is a can of worms we don't want to open. (Or open again. It's still open in GHC's non-threaded RTS, and the worms are crawling all over the place there). So I'm going to ask a few questions about the semantics of non- concurrent reentrant calls, and if people can provide answers that don't scare me, I'll concede that they have a place in the language standard. 1.) Assume thread A and B are running. Thread A makes a non- concurrent, reentrant call to Foreign Lands. The foreign function calls a foreign-exported Haskell function 'foo'. While 'foo' is executing, does thread B resume running? 2.) Assume the same situation as in 1, and assume that the answer to 1 is yes. While 'foo' is running, (Haskell) thread B makes a non- concurrent, reentrant foreign call. The foreign function calls back to the foreign-exported Haskell function 'bar'. Because the answer to 1 was yes, 'foo' will resume executing concurrently with 'bar'. If 'foo' finishes executing before 'bar' does, what will happen? 3.) Same situation as in 1. When 'foo' is called, it forks (using forkIO) a Haskell thread C. How many threads are running now? 4.) Should there be any guarantee about (Haskell) threads not making any progress while another (Haskell) thread is executing a non- concurrent call? Two more questions, not related to semantics: 5.) Assume that Haskell Programmer A writes a Haskell library that uses some foreign code with callbacks, like for example, the GLU Tesselator (comes with OpenGL), or, as a toy example, the C Standard Library's qsort function. Should Programmer A specify "concurrent reentrant" on his foreign import? Programmer B will say "please don't", as he wants to use a Haskell implementation which doesn't support "concurrent reentrant". Programmer C will say "please do", as he wants his application's GUI to stay responsive while the library code is executing. So what should the poor library programmer A do? 6.) Why do people consider it too hard to do interthread messaging for handling a "foreign export" from arbitrary OS threads, when they already agree to spend the same effort on interthread messaging for handling a "foreign import concurrent"? Are there any problems that I am not aware of? If I am wrong and we should indeed provide non-concurrent reentrant calls in a concurrent Haskell system, then I think there should be satisfying answers to the above questions... Cheers, Wolfgang

5 13