> > Had you deprecated the non-threaded RTS, we would probably have no
> > problems described in ticket #2848 :-/
>
> > I think you'll have to deprecate it anyway, because it will be more
> > and more difficult to maintain two versions of code,
>
> we may conduct small survey on amount of usage o
Hi Bulat,
My contribution to the survey: I've used forkProcess to daemonize
a ghc program inside the haskell fuse bindings:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse
http://code.haskell.org/hfuse/System/Fuse.hsc
If removing the non-threaded RTS would break forkProcess enti
Hello Tomasz,
Saturday, December 6, 2008, 10:52:39 PM, you wrote:
> Had you deprecated the non-threaded RTS, we would probably have no problems
> described in ticket #2848 :-/
> I think you'll have to deprecate it anyway, because it will be more
> and more difficult
> to maintain two versions of
Hello Simon,
Monday, March 5, 2007, 3:59:17 PM, you wrote:
>> my Streams library [1] don't uses this thread
>> at all. for threads created with forkOS it provides excellent
>> overlapping of I/O and computations (thanks, Simon, situation was
>> *greatly* improved in 6.6). of course, it should be
Hello Simon,
Friday, March 2, 2007, 1:07:07 PM, you wrote:
>> But let me add a voice to keeping the non-threaded RTS around.
i want to mention that problem here is not the threaded RTS by itself, but
standard i/o library that works via separate i/o manager thread that
is built-in part of RTS. my
