Would forkOS instead of forkIO help in this case? On Sun, Dec 21, 2008 at 11:16 PM, Mads Lindstrøm <mads_lindstr...@yahoo.dk>wrote:
> Hi Günter > > Günther Schmidt wrote: > > Hi, > > > > in an application of mine I start a long-running operation in a thread > via > > forkIO so that the UI process doesn't get blocked. > > It just so happens, that the long-running process also takes the CPU to > > nearly 100% while it runs. > > > > During that time the run-time system does *not* switch back and forth > > between the UI-process and the long-running task, it seems that the UI > > process only gets woken up *after* the high CPU thread finishes > completely. > > > > To the effect of course that it makes no difference at all to the UIs > > responsiveness whether I use forkIO or not. > > > > The long running process is pretty atomic, it's a single query to the > > database which takes up to a minute to complete so I don't see a chance > to > > squeeze a "mainIteration" in there. > > It could be the database library, as it may use unsafe foreign calls. > Unsafe foreign calls blocks all other threads, even if you compile with > the -threaded option. See > > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#4. > > I cannot claim to know how all Haskell database libraries are > implemented, but at least some of them use unsafe foreign calls. So > which database library is you using? > > > > > What can I do? > > If the problem has to do with unsafe foreign calls, then you can > implement the database calls in a separate process. Not the easiest > options, but I can think of no other. > > > > > Günther > > > > /Mads Lindstrøm > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe