On 13/03/2010 22:54, Donn Cave wrote:
Quoth Simon Marlowmarlo...@gmail.com,
...
So it was surprising when this turned out to be incompatible
with the -threaded link option. With that option, I get one
callback from a non-main thread, and then that native thread
will die, shortly after return
On 15/03/2010 08:59, Michael Lesniak wrote:
Hello,
In one of my example programs I have a strange behaviour: it is a very
simple taskpool using STM; in pseudocode it's
1. generate data structures
2. initialize data structures
3. fork threads
4. wait (using STM) until the pool is empty and all
Hello Simon,
GC. It's likely that one of these is your problem. All of them are fixed
in 6.12.2, so if you are able to grab a snapshot and test it that would be
very helpful.
Where can I get version is 6.12.2? According to [1], there are both
6.13... and 6.12.1, but I did not find 6.12.2.
On 15/03/2010 12:06, Michael Lesniak wrote:
Hello Simon,
GC. It's likely that one of these is your problem. All of them are fixed
in 6.12.2, so if you are able to grab a snapshot and test it that would be
very helpful.
Where can I get version is 6.12.2? According to [1], there are both
Quoth Simon Marlow marlo...@gmail.com,
... Does the wrapper rts_lock() account
for everything, or do threads need some initial setup I need to
account for?
Nope, as long as the RTS is initialised properly via hs_init() you
should be able to make callbacks from any OS thread.
Thanks - I'm
On 13/03/2010 20:39, Dan Knapp wrote:
There doesn't seem to be a mailing list for Cabal itself, so I'm
posting here. I came up with an idea for a small feature that I
believe would make a useful addition to ghc-pkg and Cabal. I'm
willing to implement it myself, but I have had some previous
Hello Simon,
with 6.12.1.20100313 the behaviour is worse: even when using $! in the
appropiate lines (see [2] in my original message) the programs hangs
quite often. Hence, 6.12.1 works better in this (special?) case.
Any other things I can do to help identifying the problem?
Cheers,
Michael
Hello,
I have implemented a small extension to the FFI which allows for
static_wrapper imports. These are a variation on wrapper imports
that do not use run-time code generation. This is important in
security sensitive contexts because it avoids executable data. While
static_wrapper imports are
On 15/03/10 16:02, Michael Lesniak wrote:
Hello Simon,
with 6.12.1.20100313 the behaviour is worse: even when using $! in the
appropiate lines (see [2] in my original message) the programs hangs
quite often. Hence, 6.12.1 works better in this (special?) case.
Ok, I'll look into it, thanks for
On March 15, 2010 12:48:02 Iavor Diatchki wrote:
I have implemented a small extension to the FFI which allows for
static_wrapper imports. These are a variation on wrapper imports
that do not use run-time code generation. This is important in
security sensitive contexts because it avoids
Hi,
I think that one may view a static_wrapper import as a pair of an
export like the one you wrote and an import of the address of the
exported function (this is useful because usually it is convenient to
install the handler on the Haskell side). Perhaps that's a better way
to explain its
Thanks for your feedback. I'm mailing cabal-devel before I proceed.
Hopefully the
next time I post here will be with an implementation. :)
On Mon, Mar 15, 2010 at 11:38 AM, Simon Marlow marlo...@gmail.com wrote:
On 13/03/2010 20:39, Dan Knapp wrote:
There doesn't seem to be a mailing list
12 matches
Mail list logo
