I'm trying to model an Asynchronous I/O call/interface against a
synchronous Haskell call.
I want the behavior of an unsafe blocking foreign call, without blocking in
the foreign call itself.
On Tue, Jan 8, 2019 at 6:24 PM Carter Schonwald
wrote:
> What’s the underlying problem you’re trying t
What’s the underlying problem you’re trying to model?
On Tue, Jan 8, 2019 at 3:56 AM Phyx wrote:
> > Oh, I see :( I guess it's not that easy of a fix then. Perhaps the
> RTS could use a new intrinsic for blocking on foreign state
>
> Yeah, that's what I was/am currently working on, "IOPort" ha
> Oh, I see :( I guess it's not that easy of a fix then. Perhaps the RTS
could use a new intrinsic for blocking on foreign state
Yeah, that's what I was/am currently working on, "IOPort" has much of the
same property of MVar but doesn't have this deadlock guarantee and only
supports a single put
> Maybe that should be considered a false positive (bug) for the deadlock
checker? Just because the Haskell runtime has a single thread, that
doesn't imply the whole program is necessarily single-threaded (in the
presence of foreign things). I'd think this is a legitimate use case for
MVars.
Per
> I did try removing this check to see, but it really didn't like that. It
> caused GC to be triggered over and over again as the RTS tried desperately
> to find something to do, doesn't seem to consider "do nothing" as a valid
> state.
Oh, I see :( I guess it's not that easy of a fix then. Perh
Okay, I skimmed rts/Schedule.c and now see the problem you mentioned :(
> On the non-threaded runtime the timeslice case doesn't apply and you only
> have one capability, it will force a GC to try to revive some tasks, and if
> at the end of
> this the tasks are still blocked it will release one i
I have simply copy pasted the code you provided. Note that my actual code
code doesn't pass anything to a foreign interface. It stores everything in
a Haskell mutable object.
The RTS on completion of actions simply schedules a task which inspects
this objects and wakes up as many blocked tasks as p
Strange, how could the scheduler assume a deadlock if the MVar could be called
from a closure that is still alive? Can you show the code that you're testing?
On Mon, Jan 7, 2019, at 14:09, Phyx wrote:
> Hi Phil,
>
> Thanks for the reply, however that just gives me a forced deadlock removal
>
Hi John,
I can, but the only reason that would work is because a blocking foreign
call is except from the
deadlock detection code. I can't block on the Handle itself as all the I/O
calls are non-blocking for performance reasons.
Instead what I want to do is just pause the current task, which mea
Hi Phil,
Thanks for the reply, however that just gives me a forced deadlock removal
as before.
new bound thread (1)
cap 0: schedule()
cap 0: running thread 1 (ThreadRunGHC)
cap 0: thread 1 stopped (blocked on an MVar)
thread1 @ 03205388 is blocked on an MVar @
032040c8
Can you use an os-level structure? E.g. block on a file descriptor, socket,
or something like that?
On Sun, Jan 6, 2019, 10:37 Phyx Hi All,
>
> I'm looking for a way to block a task indefinitely until it is woken up by
> an external event in both the threaded and non-threaded RTS and returns a
>
What if you wrap the MVar in a foreign closure?
import Control.Concurrent.MVar (newEmptyMVar, putMVar, takeMVar)
import Control.Exception (bracket)
import Foreign.Ptr (FunPtr, freeHaskellFunPtr)
foreign import ccall "wrapper" wrapAwaken :: IO () -> IO (FunPtr (IO ()))
main =
Hi All,
I'm looking for a way to block a task indefinitely until it is woken up by
an external event in both the threaded and non-threaded RTS and returns a
value that was stored/passed. MVar works great for the threaded RTS, but
for the non-threaded there's a bunch of deadlock detection in the sc
13 matches
Mail list logo
