Yitzchak Gale wrote:
Judah Jacobson wrote:
I'm writing a program that reads input from the user but should also
handle a ctrl-c...
It works fine compiled without -threaded, but with -threaded
it blocks forever after a ctrl-c.
Simon Marlow wrote:
Ah, this is a consequence of the change we made
Judah Jacobson wrote:
>> I'm writing a program that reads input from the user but should also
>> handle a ctrl-c...
>> It works fine compiled without -threaded, but with -threaded
>> it blocks forever after a ctrl-c.
Simon Marlow wrote:
> Ah, this is a consequence of the change we made to stdin/st
Brandon S. Allbery KF8NH wrote:
On 2008 Jun 11, at 0:43, Simon Marlow wrote:
Unix semantics just isn't the right thing when it comes to
non-blocking I/O. If only there were non-blocking read()/write()
system calls, we'd be fine.
Have you considered using aio_read() and company?
aio is n
On 2008 Jun 11, at 0:43, Simon Marlow wrote:
Unix semantics just isn't the right thing when it comes to non-
blocking I/O. If only there were non-blocking read()/write() system
calls, we'd be fine.
Have you considered using aio_read() and company?
--
brandon s. allbery [solaris,freebsd,p
Judah Jacobson wrote:
Hi all,
I'm writing a program that reads input from the user but should also
handle a ctrl-c. My attempt is below; the program forks a thread to
read one character of input, and kills that thread upon receiving a
sigINT. It works fine compiled without -threaded, but with
Hi all,
I'm writing a program that reads input from the user but should also
handle a ctrl-c. My attempt is below; the program forks a thread to
read one character of input, and kills that thread upon receiving a
sigINT. It works fine compiled without -threaded, but with -threaded
it blocks fore