🚀 go-pugleaf

Rick Johns (rjohns@bnr.ca) wrote:
: Under HP-UX you can use ioctl to get a signal
: raised on keyboard input.  This is useful for
: non-blocking i/o.  However, I don't see how to
: do it with g++ under Linux.

: Any hints?

: -- 
: Cheers,
:  Rick Johns
:  Nortel 
:  rjohns@nortel.ca

in linux we have a nice thing called ncurses, type man ncurses and 
you can see how its all done. Basicaly in unix all data is transmited
to the program line by line by default for the ttys, if you set it to
char by char, it will work that way..

Derek Young
bleach@ionet.net

Derek Young wrote:
> 
> Rick Johns (rjohns@bnr.ca) wrote:
> : Under HP-UX you can use ioctl to get a signal
> : raised on keyboard input.  This is useful for
> : non-blocking i/o.  However, I don't see how to
> : do it with g++ under Linux.
> 
> in linux we have a nice thing called ncurses, type man ncurses and
> you can see how its all done. Basicaly in unix all data is transmited
> to the program line by line by default for the ttys, if you set it to
> char by char, it will work that way..

Thanks, but what I meant was that once you have non-blocking i/o, it
can be really useful to not have to check for it.  On the HP, my
program chugs along until you type a character, at which time a SIGIO
signal is raised, the signal handler collects input and does something
with it, then returns and the normal stuff picks up again.  The idea
is that you can announce your intention to break in by hitting Return,
then get a prompt.  This is an emulator for an existing system so it
really needs to behave that way, and performance is critical.

So it comes down to: can I get a a signal raised when a character is
typed, or do I have to have a seperate process or thread waiting for it?
That might be the better answer but the old way is certainly convenient.

-- 
Cheers,
 Rick Johns
 Nortel 
 rjohns@nortel.ca

In article <31CAB1CB.3B4C@bnr.ca>, Rick Johns  <rjohns@bnr.ca> wrote:
>Derek Young wrote:
>> 
>> Rick Johns (rjohns@bnr.ca) wrote:
>> : Under HP-UX you can use ioctl to get a signal
>> : raised on keyboard input.  This is useful for
>> : non-blocking i/o.  However, I don't see how to
>> : do it with g++ under Linux.
>> 
>> in linux we have a nice thing called ncurses, type man ncurses and
>> you can see how its all done. Basicaly in unix all data is transmited
>> to the program line by line by default for the ttys, if you set it to
>> char by char, it will work that way..
>
>Thanks, but what I meant was that once you have non-blocking i/o, it
>can be really useful to not have to check for it.  On the HP, my
>program chugs along until you type a character, at which time a SIGIO
>signal is raised, the signal handler collects input and does something
>with it, then returns and the normal stuff picks up again.  The idea
>is that you can announce your intention to break in by hitting Return,
>then get a prompt.  This is an emulator for an existing system so it
>really needs to behave that way, and performance is critical.
>
>So it comes down to: can I get a a signal raised when a character is
>typed, or do I have to have a seperate process or thread waiting for it?
>That might be the better answer but the old way is certainly convenient.

SIGIO probably does not work for TTYs in Linux (it does not work _well_ for
TTYs in any other UNIX I have seen (and it does not work at all for pipes)). 
However, SIGIO does work for sockets.

If you don't want to rewrite the code to use sockets, you might try forking
and having a child process check for input (using select()).  When there is
some, send sigio to the parent.

If only UNIX had true asynchronous event support...
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

: SIGIO probably does not work for TTYs in Linux (it does not work _well_ for
: TTYs in any other UNIX I have seen (and it does not work at all for pipes)). 
: However, SIGIO does work for sockets.
    SIGPOLL for STREAM/based ttys, but don't think so on Linux.

: If only UNIX had true asynchronous event support...

    It does with the new shiny Asynchronous IO POSIX(.4?) stuff ...
    Check out "aio_{read|write|cancel|suspend|error}(3)".

    BUT, you still have to roll your own event/handlers stuff on top.
    And I don't know how it interacts with terminals.

    But you're right, I'd kill for a lightweight, standardised event library.

    Random Gripe:
        It always seemed a shame to me that the X system was not partitioned a 
        bit more. 
        I always wondered why all the windowing stuff was not built on top
        of a general substrate library which handled 
        IPC/distributed/event/resource ops.  
        X has some very useful stuff to do events, handlers, event-registration,
        timers, idle-work functions and such, but it is all hardwired in. 
        Damn, there's a lot of good code in there, on all of my systems, 
        but which is all usable ONLY for windowing.
        For instance, (correct me WHEN I'm wrong), but you can't even use the 
        resource file parsing ops without a connection to an X server. 


--
+-------------------------------------------------+----------------------------+
|   Rumours persist that Kelly is alive.          | Ronan Kelly at Xsoft EDV   |
|   But conclusive proof has not been obtained.   | Project Manager            |
|   If sighted, do not approach. Observe then     | email: kelly@xsoft.co.at   |
|   report to the relevant authorities.           |   Tel: (+43) 1-7129317-26. |
+-------------------------------------------------+----------------------------+