select(), epoll(), etc... in GUI? - Linux

This is a discussion on select(), epoll(), etc... in GUI? - Linux ; Trying to learn how Linux handles asynchronous IO and events. I know about select(), and I have learned about epoll() and libevent. And one can always do things oneself using threads. Some questions.. How do POSIX signals work? It sounds ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: select(), epoll(), etc... in GUI?

  1. select(), epoll(), etc... in GUI?

    Trying to learn how Linux handles asynchronous IO and events. I know about
    select(), and I have learned about epoll() and libevent. And one can always do
    things oneself using threads. Some questions..

    How do POSIX signals work? It sounds like they break in like an interrupt, same
    thread...? If so, I guess one must code a signal handler function much like a
    worker thread would be coded. Except its even harder, you can't use locks
    because you don't want to block in the handler. hmm am I right? What CAN you do
    in a signal handler with regard to reading/writing program data safely?

    Are there functions for use in GUI programs? XWindows? GNOME or KDE specific? I
    mean a call like select() or epoll() that waits for events to happen but which
    will also watch for GUI events and return if those occur as well. MS Windows has
    MsgWait...() functions. So your GUI stays responsive while waiting for events.

    And now for a specific problem I want to solve. I'm creating a wxWidgets app
    that will read the serial port. I want to read only when there are bytes ready.
    I'd like to do it without using a worker thread, and without polling. It seems I
    can get serial port notifications by means of select()/epoll() or POSIX signals.
    How to make these work in the GUI program?

    thanks, any tips appreciated
    --
    _______________
    hello friend!
    i tend to ignore the following kinds of replies: top-bottom-middle posting,
    grammar, spelling, read the manual you %#!, search google you !@%... thank you

  2. Re: select(), epoll(), etc... in GUI?

    takeout schrieb:
    > Trying to learn how Linux handles asynchronous IO and events. I know about
    > select(), and I have learned about epoll() and libevent. And one can
    > always do things oneself using threads. Some questions..
    >

    This isn't asynchronous I/O. Asynchronous I/O in UNIX terms is a programming
    technique where a signal (SIGIO by default) is sent to the process as soon
    input or output is becoming possible on a file descriptor. It is set on the
    open() or fcntl() system call at seldom used.

    $ man 2 open


    > How do POSIX signals work? It sounds like they break in like an interrupt,
    > same thread...? If so, I guess one must code a signal handler function
    > much like a worker thread would be coded. Except its even harder, you
    > can't use locks because you don't want to block in the handler. hmm am I
    > right? What CAN you do in a signal handler with regard to reading/writing
    > program data safely?
    >

    Signals are processed at system calls and at scheduler action on a process.
    By default, any thread of a process receives the signal. This is because
    threads are a newer concept than signals and so there is no definition
    of "main" or "worker" thread in Unix.

    What is done then depends on the signal characteristics set with the
    sigaction() system call. Most times, you'll only want to disable certain
    signals in your program. Signal handlers are seldom used, most times only
    for cleanup before the program terminates.

    Signal handlers which do not exit the program should *never* do any system
    call. So basically, all things such signal handlers should do is modifying
    global variables of your program.

    If you mix signals and threading, you have to disable signaling
    (pthread_sigmask()) on worker threads by hand or better, avoid
    signal-driven (== async) I/O at all.


    >
    > Are there functions for use in GUI programs? XWindows? GNOME or KDE
    > specific? I mean a call like select() or epoll() that waits for events to
    > happen but which will also watch for GUI events and return if those occur
    > as well. MS Windows has MsgWait...() functions. So your GUI stays
    > responsive while waiting for events.
    >

    Most X Window toolkits have their own function for entering a "global" event
    handler. Just register events (e.g. by creating key bindings, buttons, text
    entry fields etc.), then enter that event handler. The call usually returns
    when there is no further event pending. You may create your own "non-GUI"
    event loop around that call.


    > And now for a specific problem I want to solve. I'm creating a wxWidgets
    > app that will read the serial port. I want to read only when there are
    > bytes ready. I'd like to do it without using a worker thread, and without
    > polling. It seems I can get serial port notifications by means of
    > select()/epoll() or POSIX signals. How to make these work in the GUI
    > program?
    >

    Don't know wxWidgets thoroughly enough, sorry.


    Kind regards

    Jan



  3. Re: select(), epoll(), etc... in GUI?

    Jan Kandziora writes:
    > takeout schrieb:
    >> Trying to learn how Linux handles asynchronous IO and events. I know about
    >> select(), and I have learned about epoll() and libevent. And one can
    >> always do things oneself using threads. Some questions..
    >>

    > This isn't asynchronous I/O. Asynchronous I/O in UNIX terms is a programming
    > technique where a signal (SIGIO by default) is sent to the process as soon
    > input or output is becoming possible on a file descriptor.


    These are 'asychronous I/O events', because they occur asychronously
    wrt execution of a program.

    > It is set on the open() or fcntl() system call at seldom used.


    This would be 'asychronous I/O-readiness notification', aka
    'signal-driven I/O'. This is asynchronous (or 'normally asychronous')
    because signal handlers are called by the kernel whenever needed, as
    opposed to syncronous I/O multiplexing, aka poll/ select, where the
    process either waits until an I/O-readiniess event occurs or
    ocasionally checks if something has become ready for I/O (the same can
    be implemented by combining signal-driven I/O with sigwait/
    sigwaitinfo).

    > $ man 2 open


    BUGS

    [...]

    Currently, it is not possible to enable signal-driven I/O by
    specifying O_ASYNC when calling open(); use fcntl(2) to enable
    this flag.

    >> How do POSIX signals work? It sounds like they break in like an interrupt,
    >> same thread...? If so, I guess one must code a signal handler function
    >> much like a worker thread would be coded. Except its even harder, you
    >> can't use locks because you don't want to block in the handler. hmm am I
    >> right? What CAN you do in a signal handler with regard to reading/writing
    >> program data safely?
    >>

    > Signals are processed at system calls and at scheduler action on a process.
    > By default, any thread of a process receives the signal. This is because
    > threads are a newer concept than signals and so there is no definition
    > of "main" or "worker" thread in Unix.


    This is the POSIX signalling model for threads ('signals sent to the
    process are delivered to some thread not blocking them') and exists in
    Linux since NPTL, while the older LinuxThreads-library had no concept
    of 'per process' signals. Because all threads of a process are created
    equal, there is no 'main thread' being more equal than the others. A
    likely (IMO) reason why signalling works this way is because it means
    that signals can be handled by an arbitrary thread which is currently
    not busy doing something different.

    > What is done then depends on the signal characteristics set with the
    > sigaction() system call. Most times, you'll only want to disable certain
    > signals in your program. Signal handlers are seldom used, most times only
    > for cleanup before the program terminates.


    I use them frequently for various actions, eg signal-driven I/O, all
    kinds of single-shot "events" which need to be communicated from one
    process to another, eg a configuration has been updated (quite common
    for UNIX(*)-daemons), for timers, of course and various minor things
    (like cycling through debugging levels).

    > Signal handlers which do not exit the program should *never* do any system
    > call.


    This is wrong. The general requirement for subroutines defined by the
    UNIX(*)-specification is that

    all functions defined by this volume of IEEE Std 1003.1-2001
    shall behave as defined when called from or interrupted by a
    signal-catching function, with a single exception: when a
    signal interrupts an unsafe function and the signal-catching
    function calls an unsafe function, the behavior is undefined.

    A list of 'safe' functions, to which this exception does not apply, is
    defined in

    http://www.opengroup.org/onlinepubs/...html#tag_02_04

  4. Re: select(), epoll(), etc... in GUI?

    Good info, thanks people. I have found that Xt provides XtAddInput(), GTK+
    provides IO Channels, ...and Qt provides QSocketNotify thingy(?)

    Still trying to understand the signals and how you can safely perform operations
    in them. Ahha, a least for a single threaded process, the signal handler
    function will be 'atomic' right? It will not be itself interrupted by your main
    process code. So you could define some global variables that the signal handler
    can write to, and that should be read only by the rest of the process. I don't
    think I could safely modify a GUI event queue from a signal handler though.

    I think GTK IO Channels will solve my specific problem since im using wxGTK.
    I'll try that.

    --
    _______________
    hello friend!
    i tend to ignore the following kinds of replies: top-bottom-middle posting,
    grammar, spelling, read the manual you %#!, search google you !@%... thank you.

  5. Re: understanding of signal handling details

    > Still trying to understand the signals and how you can safely perform operations
    > in them. Ahha, a least for a single threaded process, the signal handler
    > function will be 'atomic' right?


    I suggest to read more about the term "async-signal safety".
    http://groups.google.de/group/comp.l...6ae829fadc5790


    > It will not be itself interrupted by your main process code.


    Do you know how to work with reentrant functions?


    > So you could define some global variables that the signal handler can write to,
    > and that should be read only by the rest of the process.


    Do you use the data type "sig_atomic_t" for this use case?

    Regards,
    Markus

  6. Re: select(), epoll(), etc... in GUI?

    On Mon, 24 Dec 2007 14:59:02 +0100 Rainer Weikusat wrote:

    | This is the POSIX signalling model for threads ('signals sent to the
    | process are delivered to some thread not blocking them') and exists in
    | Linux since NPTL, while the older LinuxThreads-library had no concept
    | of 'per process' signals. Because all threads of a process are created
    | equal, there is no 'main thread' being more equal than the others. A
    | likely (IMO) reason why signalling works this way is because it means
    | that signals can be handled by an arbitrary thread which is currently
    | not busy doing something different.

    Is there a way to direct all signals to one thread or a specific group
    of threads ... or better yet ... have a new thread launched for each
    arriving signal that ends when handling the signal is done (e.g. just
    go to the signal handler withuot blocking any existing thread)?

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-12-25-2143@ipal.net |
    |------------------------------------/-------------------------------------|

  7. Re: select(), epoll(), etc... in GUI?

    On Dec 25, 7:45 pm, phil-news-nos...@ipal.net wrote:

    > Is there a way to direct all signals to one thread or a specific group
    > of threads ... or better yet ... have a new thread launched for each
    > arriving signal that ends when handling the signal is done (e.g. just
    > go to the signal handler withuot blocking any existing thread)?


    Yes to all of these.

    DS

+ Reply to Thread