If I understood this right, then I can use forkIO to run a
"safe" FFI function which blocks, but in the threaded RTS
this will not block all other FFI calls.
Right.
So what happens in the non-threaded RTS? Now the blocking
yet "safe" FFI invocation _would_ block other FFI calls but
not evaluation o
Simon Marlow writes:
> When you compile your program with -threaded, "safe" FFI
> calls don't block other threads, but "unsafe" calls still
> do. Basically a "safe" FFI call releases the lock on the
> RTS so other Haskell threads can continue to run [...].
Thanks for the clarification.
If I
> On 02 February 2005 19:48, Peter Simons wrote:
>
> > Wolfgang Thaller writes:
> >
> > > a) poll() is not supported on Mac OS X and (at least some
> > > popular versions of) BSD.
> >
> > Are you certain? Just tried "man poll" on one of the MacOS X
> > machines the SourceForge compile farm off
On 02 February 2005 19:48, Peter Simons wrote:
> Wolfgang Thaller writes:
>
> > a) poll() is not supported on Mac OS X and (at least some
> > popular versions of) BSD.
>
> Are you certain? Just tried "man poll" on one of the MacOS X
> machines the SourceForge compile farm offers, and that one
Wolfgang Thaller writes:
> a) poll() is not supported on Mac OS X and (at least some
> popular versions of) BSD.
Are you certain? Just tried "man poll" on one of the MacOS X
machines the SourceForge compile farm offers, and that one
had it: "Darwin ppc-osx1 5.5 Darwin Kernel Version 5.5".
>
So I guess I can't really use them in code that's supposed
to be portable among different platforms?
Maybe 'forkOS' combined with calling poll() through FFI
really is the best solution? I seem to recall reading
somewhere that the threaded RTS was more efficient for these
applications anyway?
Two mi
Tomasz Zielonka writes:
>> Like select(2) or poll(2) would do?
> You seem to what something low-level.
Well, my point is that I don't really want to deal with the
file descriptors. What I'd really like to do is to register
a call-back function; similar to the way signal handlers
work. I don't
On Wed, Feb 02, 2005 at 05:58:58AM -0800, Peter Simons wrote:
> Tomasz Zielonka writes:
>
> > threadWaitRead :: Int -> IO ()
> > threadWaitWrite :: Int -> IO ()
>
> Thanks for the pointer!
>
> Am I correct in assuming that there is no "more high-level"
> mechanism for scheduling more t
Hi!
On Wed, Feb 02, 2005 at 02:57:24PM +0100, Peter Simons wrote:
> Tomasz Zielonka writes:
>
> > threadWaitRead :: Int -> IO ()
> > threadWaitWrite :: Int -> IO ()
>
> Thanks for the pointer!
>
> Am I correct in assuming that there is no "more high-level"
> mechanism for scheduling
Tomasz Zielonka writes:
> threadWaitRead :: Int -> IO ()
> threadWaitWrite :: Int -> IO ()
Thanks for the pointer!
Am I correct in assuming that there is no "more high-level"
mechanism for scheduling more than one file descriptor? Like
select(2) or poll(2) would do?
I guess, I could i
On Tue, Feb 01, 2005 at 03:16:44PM -0800, Peter Simons wrote:
> Hi,
>
> I have the following problem: I use an external library
> through the foreign function interface which gives me
> _several_ sockets and expects me to call it again when any
> of those sockets becomes readable or writable.
>
>
Hi,
I have the following problem: I use an external library
through the foreign function interface which gives me
_several_ sockets and expects me to call it again when any
of those sockets becomes readable or writable.
Since I know that the Haskell run-time system has all the
required functional
12 matches
Mail list logo
