loadtest: internal error: traverse_weak_ptr_list: not WEAK
Please report this as a bug to glasgow-haskell-bugs(a)haskell.org,
or http://www.sourceforge.net/projects/ghc/
Has anyone seen this before? I got this after running a 1,300 socket
connections for a while (probably x3 threads overall). Any workarounds?
Thanks, Joel
--
http://wagerlabs.com/
How do unbound threads play with FFI? According to Simon PJ, each
foreign call will get its own OS thread if its blocked.
How does GHC determine if the call is blocked? Does each call get its
own OS thread from the start? Sometime later? Does this depend on the
safe/unsafe specs of the foreign call?
Does the above change if a threaded/non-threaded runtime is in use?
Thanks, Joel
--
http://wagerlabs.com/
Folks,
How does killThread work with FFI calls? What happens at the low
level when a thread is blocked on an FFI call and received a
KillThread exception? Does it exit immediately via some GHC magic or
is the exception caught when the FFI call returns?
Thanks, Joel
--
http://wagerlabs.com/
There is a new version of Djinn available, with two notable
new features: Haskell data types can be defined and the
found functions are sorted (heuristically) to present the
best one first.
To play with Djinn do a
darcs get http://darcs.augustsson.net/Darcs/Djinn
or get
http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz
Then just type make. (You need a Haskell 98 implementation and
some libraries.) And then start djinn.
`-- Lennart
On 14 December 2005 09:57, Tomasz Zielonka wrote:
> On Wed, Dec 14, 2005 at 09:51:16AM -0000, Simon Marlow wrote:
>>> Here is an example how you can initialize a top-level STM variable.
>>> http://www.uncurry.com/repos/TimeVar/TimeVar.hs
>>> It just forks a new thread inside unsafePerformIO, it runs
>>> "atomically" in it and passes the result through ordinary MVar.
>>
>> A cheaper way is just to seq the top-level TVar at the beginning of
>> Main.main.
>
> Yes, I tried that approach. However, imagine telling users of
> your library to do that in every program (withSocketsDo comes
> to mind).
Well sure, but it's only a temporary problem. And you also have to tell
them to use {-# NOINLINE #-} and -fno-cse :-)
Cheers,
Simon
On 13 December 2005 18:34, Tomasz Zielonka wrote:
> On Tue, Dec 13, 2005 at 06:08:23PM +0000, Joel Reymont wrote:
>> Can this be done now or is this a GHC 6.5 feature?
>>
>> My combination of unsafePerformIO with atomically $ newTVar does not
>> seem to be working.
>
> Here is an example how you can initialize a top-level STM variable.
> http://www.uncurry.com/repos/TimeVar/TimeVar.hs
> It just forks a new thread inside unsafePerformIO, it runs
> "atomically" in it and passes the result through ordinary MVar.
A cheaper way is just to seq the top-level TVar at the beginning of
Main.main.
Cheers,
Simon
newTVarIO in the HEAD, and therefore it's in any nightly-build snapshot,
which you can freely download.
The next major release will be 6.6, but it's a few months off.
Meanwhile I hope you can use the workaround that Tomasz posted.
Simon
| -----Original Message-----
| From: haskell-cafe-bounces(a)haskell.org
[mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Joel
| Reymont
| Sent: 13 December 2005 18:08
| To: Haskell-Cafe Cafe
| Subject: [Haskell-cafe] Top-level TVars
|
| Can this be done now or is this a GHC 6.5 feature?
|
| My combination of unsafePerformIO with atomically $ newTVar does not
| seem to be working.
|
| Thanks, Joel
|
| P.S. What is the ETA for 6.5?
|
| On Mon, Dec 05, 2005 at 10:50:13AM -0000, Simon Peyton-Jones wrote:
| >
| > It turns out to be easy to provide
| >
| > newTVarIO :: a -> IO (TVar a)
| >
| > which you can call from inside 'unsafePerformIO'. That means you
can
| > allocate top-level TVars without fuss.
| >
|
| --
| http://wagerlabs.com/
|
|
|
|
|
| _______________________________________________
| Haskell-Cafe mailing list
| Haskell-Cafe(a)haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
Can this be done now or is this a GHC 6.5 feature?
My combination of unsafePerformIO with atomically $ newTVar does not
seem to be working.
Thanks, Joel
P.S. What is the ETA for 6.5?
On Mon, Dec 05, 2005 at 10:50:13AM -0000, Simon Peyton-Jones wrote:
>
> It turns out to be easy to provide
>
> newTVarIO :: a -> IO (TVar a)
>
> which you can call from inside 'unsafePerformIO'. That means you can
> allocate top-level TVars without fuss.
>
--
http://wagerlabs.com/
Folks,
I need some help from those of you with a FreeBSD box.
It looks like 'ulimit -n' on FreeBSD lets you have 10k+ file
descriptors open per process. FD_SETSIZE is 1024 in the system
headers, though. GHC relies on this value (see ghc/rts/Select.c).
Normally, you will get the EMFILE error if you try to open more
sockets than what is allowed with 'ulimit -n'. If you allow yourself
more than 1024 descriptors per process then you do not get this error
but...
This seems to lead to a situation where you open more than 1024
sockets and shortly afterwards get 'connection resets' for some or
all of your sockets. Maybe just those above 1024, I have not
determined this precisely.
My question is this: is it possible to get a higher number of open
sockets by editing the system header files on FreeBSD and recompiling
GHC? Has anyone tried this before? How high can you go?
Thanks, Joel
--
http://wagerlabs.com/
