[Sorry, I accidently mailed this to the -bugs list. See its archives for the
complete source]
On Thu, Jul 29, 1999 at 12:19:10 +0200, George Russell wrote:
> I would like to add my strong support, as the person in charge of
> transferring the UniForM workbench, for the implementation of wait
> functions on input and output handles and input on Posix.FD which don't
> block everything else to be done urgently.
Wanna have a workaround for this? :-)
Today, I was playing around with green-card, and now I do have an (almost)
non-blocking hGetline...
Consider this piece of code, which was suggested by Peter Amstutz, who
started this thread:
\begin{code}
main = do
hSetBuffering stdin NoBuffering
forkIO (loop 'a')
booga
where
loop ch = hPutChar stdout ch >> loop ch
booga = do out <- almostPreemptiveGetLine 100 stdin
hPutStrLn stdout out
booga
\end{code}
After starting this program, you get blasted by 'a' chars, and if you type
in a line (still getting your terminal full of a's), it is printed in the
middle of these a's, just as one would expect...
Do I get a cookie now? :-)
How was this achieved?
Basically, I made a Haskell wrapper for select(2), so if one needs another
preemptive Input/Output function, it is possible to (non-blockingly) test,
whether there is I/O ready...
This is not really a solution, but I bet, it'll work in quite some
situations until Concurrent Haskell is *really* preemptive. ;-)
BTW: This should work with sockets, too, I didn't test, but I did a directly
coded (i.e. without green-card), similar function for sockets some weeks
ago, which worked...
Cheers,
Michael
--
"Don't worry about people stealing your ideas. If your ideas are any
good, you'll have to ram them down people's throats."
-- Howard Aiken
