Manuel M. T. Chakravarty | 2 Jun 2001 09:33
Picon
Picon
Favicon
Gravatar

Weak pointers, garbage collection & deadlocks

While using weak pointers and concurrency together, I became
convinced that before issuing the ``no threads to run:
infinite loop or deadlock?'' error message, the RTS should
perform a GC.  The reason is that the GC may run some
finalisers, which in turn may unlock some threads.

The concrete scenario that I have is that I use a finaliser
to close a stream when the handle that provides input to
that stream dies.  Now if the only other thread is a
consumer of that stream that waits for it to close, then
this thread can't run before the next GC is performed and
runs the finaliser.

Opinions?

Cheers,
Manuel

Saswat Anand | 2 Jun 2001 11:13
Picon

Instance Declaration discrepancy

class MyShow a where
 sh :: a -> String

instance (Integral a) => Show a where
 sh = "Integer " + show a

Ghc 5.00.1 (with -fglasgow-exts) does not accept the above, while hugs with
extensions has no problem with this. Is it a bug?

Thanks,
S

Saswat Anand | 2 Jun 2001 11:23
Picon

Re: Instance Declaration discrepancy

> I am sorry for the typos. It should have been
> 
> instance (Integral a) => Show a where
>  sh a = "Integer " ++ (show a)
> 
> 
> 
> class MyShow a where
>  sh :: a -> String
> 
> instance (Integral a) => Show a where
>  sh = "Integer " + show a
> 
> Ghc 5.00.1 (with -fglasgow-exts) does not accept the above, while hugs
> with extensions has no problem with this. Is it a bug?
> 
> Thanks,
> S
> 
> 
> 
> 
> 

Saswat Anand | 4 Jun 2001 09:04
Picon
Favicon

Seq ??

In ghc-5.00.1, "seq (2/0) 3" gives 3. Should it not give error. Hugs does.

Thanks,
S

Simon Peyton-Jones | 4 Jun 2001 10:34
Picon
Favicon
Gravatar

RE: Instance Declaration discrepancy

You need -fallow-undecidable-instances as well.

Simon

| -----Original Message-----
| From: Saswat Anand [mailto:iscp9157 <at> nus.edu.sg] 
| Sent: 02 June 2001 10:13
| To: 'glasgow-haskell-users <at> haskell.org'
| Subject: Instance Declaration discrepancy
| 
| 
| 
| class MyShow a where
|  sh :: a -> String
| 
| instance (Integral a) => Show a where
|  sh = "Integer " + show a
| 
| Ghc 5.00.1 (with -fglasgow-exts) does not accept the above, 
| while hugs with extensions has no problem with this. Is it a bug?
| 
| Thanks,
| S
| 
| 
| 
| 
| 
| 
| _______________________________________________
(Continue reading)

Malcolm Wallace | 4 Jun 2001 11:56
Picon

Re: Seq ??

> In ghc-5.00.1, "seq (2/0) 3" gives 3. Should it not give error. Hugs does.

I suspect that Hugs is wrong and ghc is right in this case.
Certainly nhc98 and hbc agree with ghc's behaviour.

seq x y  means evaluate x to whnf and throw away the result, returning
y instead.  It shouldn't matter whether the result of x is bottom.

Regards,
    Malcolm

Julian Seward (Intl Vendor | 4 Jun 2001 12:21
Picon
Favicon

RE: Seq ??

| > In ghc-5.00.1, "seq (2/0) 3" gives 3. Should it not give 
| error. Hugs does.
| 
| I suspect that Hugs is wrong and ghc is right in this case. 
| Certainly nhc98 and hbc agree with ghc's behaviour.
|
| seq x y  means evaluate x to whnf and throw away the result, 
| returning y instead.  It shouldn't matter whether the result 
| of x is bottom.

This doesn't seem a correct explaination to me.  seq _|_ anything == _|_

The reason that it doesn't bomb in GHCi, and I presume nhc98 and hbc is
because the type of (2/0) is Fractional a => a, which is defaulted to
Double.  However, 2/0 :: Double is a well defined value -- an IEEE754 
Infinity (try it)!  

I think what Saswat expected to see can be made to happen if you force
the division to be an integer division:

   Prelude> seq (2 `div` 0) 3    
   Floating point exception
   cam-02-unx:~$ 

J

Simon Marlow | 4 Jun 2001 12:29
Picon
Favicon

RE: Socket Behaviour

> Can anyone tell me why the following code doesn't work as 
> expected? Both the server and client hang. If I run
> 
> server 20000 &
> and 
> client <hostname> 20000
> 
> the server logfile produces
> 
> [dom <at> lhrtba8fd85 twotest]$ more log.txt
> Thu May 31 14:35:39 BST 2001
> Starting logging
> Thu May 31 14:36:08 BST 2001
> Hello world    48 65 6c 6c 6f 20 77 6f 72 6c 64               

It only produces this logfile if you kill the client with ^C before
killing the server.

What's happening is this:  the client writes the string "Hello World" to
the socket.  The server picks it up, but it is waiting for an end of
file before returning the string, so it hangs.  When you kill the
client, the server finally gets EOF and returns Partial "Hello World"
from getBuffer.  

At this point, the server gets a SIGPIPE because it attempts to write to
a socket whose other end has disappeared.  The default behaviour when
receiving a SIGPIPE is to terminate silently (this behaviour has caught
me out a couple of times - the documentation for Socket mentions it), so
this is what the server does, leaving the logfile that you see above.
If you arrange for the server to ignore SIGPIPE, by adding the line
(Continue reading)

Steinitz, Dominic J | 4 Jun 2001 18:20
Favicon

RE: Socket Behaviour

Simon, Thanks very much for this. Dominic.

-------------------------------------------------------------------------------------------------
21st century air travel     http://www.britishairways.com

Leon Smith | 5 Jun 2001 00:59
Picon

Problems finding modules with GHC 5

I'm having problems running programs that use modules found in
the hslibs libraries.  I've tried these with GHC 5.00.1 on both
a x86 Linux box on which I compiled GHC from source, and a Sparc 
box where I installed the precompiled binaries.

If I simply try to load my program (which uses MArray), I get:

--------

$ ghci Main.hs
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 5.00.1, For Haskell
98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package std ... linking ... done.
ghc-5.00.1: can't find module `MArray'

---------

If I try using the -i option, I get 

---------

$ ghci -i/usr/local/lib/ghc-5.00.1/imports/lang/ Main.hs

...

(Continue reading)


Gmane