- Haskell-Cafe - Haskell.org

haskell DNS resolver w/o using FFI
by S. Alexander Jacobson 04 Mar '05

04 Mar '05

Peter Simons told me that someone has written a DNS resolver in Haskell that doesn't rely on an FFI call. I'd love to look at it if it is available... -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

2 1

getting the name of a function for test diagnostic purposes
by Terrence Brannon 03 Mar '05

03 Mar '05

{- I have written a program (below) to run a test suite for a list of functions: [isTotalJunc, isPartialJunc] where each function receives a datum of type ApplyArg whose value slot is one element at a time of the list of types below: [JNone, JOne, JAny, JAll] I therefore must run 8 tests (the cross product of functions and types). Right now, here is the output: *Main> test_total_partial ["fun: (->)input: JNoneoutput: True","fun: (->)input: JOneoutput: False","fun: (->)input: JAnyoutput: False","fun: (->)input: JAlloutput: True","fun: (->)input: JNoneoutput: False","fun: (->)input: JOneoutput: True","fun: (->)input: JAnyoutput: True","fun: (->)input: JAlloutput: False"] -- One problem is that functions do not print as their name. The call to (show f) in showres simply yields (->) -- Another problem is that I cannot manage to separate each string with a carriage return. Any help with these problems is appreciated. -} test_total_partial = let funs = [isTotalJunc, isPartialJunc] types = [JNone, JOne, JAny, JAll] mkdat typ = ApplyArg "somename" (VJunc $ Junc typ emptySet emptySet) False showres f t r = "fun: " ++ (show f) ++ "input: " ++ (show t) ++ "output: " ++ (show r) runtest f t = do { retval <- f (mkdat t); return $ (showres f t retval) } in [ (showres f t (f (mkdat t))) | f <- funs, t <- types ] -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality.

2 2

Re: [Haskell] specified or not
by Ross Paterson 03 Mar '05

03 Mar '05

[moving to the cafe] On Thu, Mar 03, 2005 at 09:39:17AM -0500, Scott Turner wrote: > Is the behavior of evaluating z unspecified? > z = f (0, z) > f x = case x of > (1,1) -> z > _ -> 0 > Hugs and GHC agree that z evaluates to 0. However, if the first line is > changed to > z = f (z,0) > then both implementations loop. In other words, the behavior depends on order > of evaluation, which AFAIK is not specified. The order of pattern matching is specified: pre-order, left to right. In detail: according to the rules of Section 3.17.3 of the Report, the definition of f is equivalent to f x = case x of (x1, x2) -> case x1 of 1 -> case x2 of 1 -> z _ -> 0 _ -> 0 _ -> 0 and hence f (0, anything) = 0 f (undefined, 0) = undefined

1 0

Re: [Haskell-cafe] Re: Bound threads
by Wolfgang Thaller 03 Mar '05

03 Mar '05

Marcin Kowalczyk wrote: > Indeed, my brain is melting, but I did it :-) Congratulations. How about we found a "Bound-thread-induced brain melt victims' support group"? > [...] I have added some optimizations: I think we had thought of most of these optimizations, but things were already very complex, so I kept putting that off until we decided to do IO differently, at which point they were no longer necessary. Besides simplicity, one of the main reasons for moving our select() call from the run-time system to the libraries was to avoid the performance hit of having to call select() every time through the scheduler loop rather than only once per IO operation. Imagine having one or more (unbound) threads that spend most of their time waiting for IO, and a bunch of (also unbound) threads that do some computation. If select() is part of the scheduler loop, you will get a select() call whenever a thread-switch between the computation threads happens. If, on the other hand, the select() call happens in a separate OS thread, you will get extra inter-OS-thread messaging once the select wakes up, but that happens far less often as a thread-switch between the computation threads. > Bound threads introduced problems. They can partially be solved, > e.g. the worker pool, the wakeup pipe, epoll descriptor are correctly > recreated. But there is simply no way to return from callbacks because > the corresponding C contexts no longer exist. So I made them as > follows: > > All threads except the thread performing the fork become unbound. > [...] What happens when fork is called from an unbound thread? Does it become bound in the child process? When does the child process terminate? Does the thread that called fork gain a "main thread" status so that the process will exit as soon as the thread exits? For GHC, we side-stepped all those issues by only providing a simplified version of forkProcess: System.Posix.forkProcess :: IO () -> IO System.Posix.Types.ProcessID In the child process, only the IO action given as a parameter will run, and once it returns, the child process will terminate. This covers most use cases of fork and is, to the best of my knowledge, the most general version that can be implemented with the same semantics for both GHC's threaded RTS and GHC's non-threaded RTS. > I measured the speed of some syscalls on my system, to see what is > worth optimizing: > > - pthread_mutex_lock + unlock (NPTL) 0.1 us pthread_mutex_* is not necessarily a syscall. When there is no contention, the NPTL is able to do it entirely in user space without a context switch. The kernel only gets involved when a thread is actually suspended waiting for a lock. The situation is the same on Mac OS X, but Microsoft's multithreading API is rumored to be a lot slower (kernel calls for every lock/unlock - I haven't checked this, though). Cheers, Wolfgang

2 1

RE: [Haskell-cafe] Re: Bound threads
by Simon Marlow 03 Mar '05

03 Mar '05

On 01 March 2005 11:21, Marcin 'Qrczak' Kowalczyk wrote: > Marcin 'Qrczak' Kowalczyk <qrczak(a)knm.org.pl> writes: > >> Why is the main thread bound? > > I can answer myself: if the main thread is unbound, the end of the > program can be reached in a different OS thread, which may be a > problem if we want to return cleanly to the calling code. > > I've now implemented a threaded runtime in my language Kogut, based > on the design of Haskell. The main thread is bound. The thread which > holds the capability performs I/O multiplexing itself, without a > separate service thread. We found that doing this was excessively complex (well, I thought so anyway). The problem is, when there is no other work to do but there are outstanding I/O requests to wait for, the thread holding the capability has to wait in select(). But then, another OS thread making an external call into Haskell has to somehow indicate that it needs the capability, and wake up the thread blocked in select(). It can do this with a pipe, but then you still have the problem that each call-in requires a context switch, which is sub-optimal if you're implementing a library in Haskell to be called from another language. > Producer/consumer ping-pong is 15 times slower between threads running > on different OS threads than on two unbound threads. You might also want to measure throughput of call-ins. Cheers, Simon

2 1

how do I avoid excessive constructor application?
by S. Alexander Jacobson 02 Mar '05

02 Mar '05

For some reason, these two functions have different types. fun1 f (Left x)= Left (f x) fun1 _ r@(Right x) = Right x fun2 f (Left x) = Left (f x) fun2 _ r = r Is there a way to rewrite fun2 so that f has type (a->b)? In the general case, it seems wasteful to have to destruct and construct values just for type checking reasons, especially if your type has many more constructors than (Either a b). -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

6 9

Numeric vs. relative precedences of infix operators
by Henning Thielemann 02 Mar '05

02 Mar '05

Is it widely accepted that the precedence of infix operators is defined by numbers? The numbers look arbitrary to me and it is not possible to introduce infix operators with interim precedences. What about defining relations such as "(*) has precedence over (+)"? The compiler could construct a topographically ordered graph from these relations. This way it would also be possible that from two infix operators none has precedence over the other (although the have not the _same_ precedence), thus the sub-expressions with these operators must be enclosed in parentheses.

4 6

FFI and foreign function returning a structure
by Dimitry Golubovsky 02 Mar '05

02 Mar '05

Hi, If I have a C function returning a structure (not a pointer, but structure itself), can this be accomodated via FFI? I re-read the FFI Addendum, and my conclusion is most likely "No". I am asking just to make sure this is not only my finding. Dimitry Golubovsky Middletown, CT

3 2

Browser-like UI
by Maurício 02 Mar '05

02 Mar '05

Hi, I've seen some options for GUI programming in Haskell libraries page, but what I really would like is to define my user interface using HTML (or, maybe, SVG). What are the options to do that in Haskell? I've read that Gtk2Hs has a mozilla rendering engine, but unfortunatly that won't build on my 64Mb computer. What else can I use? How does that work, can I handle HTML events with Haskell code? Thanks, Maurício

3 3

RE: [Haskell-cafe] Re: Bound threads
by Simon Marlow 02 Mar '05

02 Mar '05

On 26 February 2005 12:14, Marcin 'Qrczak' Kowalczyk wrote: > Wolfgang Thaller <wolfgang.thaller(a)gmx.net> writes: > >>> Since the main thread is bound, and unbound threads are never >>> executed on an OS thread which has some Haskell thread bound, this >>> would imply that when the main thread spawns a Haskell thread and >>> they synchronize a lot with each other using MVars, the >>> synchronization needs OS-thread synchronization - the threads will >>> not execute on a the same OS thread. >> >> Correct. > > Is it important which thread executes Haskell code (I bet no) and > unsafe foreign calls (I don't know)? If not, couldn't the same OS > thread execute code of both threads until a safe foreign call is made? Actually in a bound thread, *all* foreign calls must be made using the correct OS thread, not just the safe ones. So your scheme would involve a context switch at every foreign call, which would end up being rather expensive. It's certainly a legitimate implementation, but I suspect not one that would lead to good performance. Cheers, Simon

3 4