software interrupt - Linux

This is a discussion on software interrupt - Linux ; On Sun, 30 Mar 2008 01:21:56 GMT, Ron Eggler wrote: >Hi, > >I would like to write a timer application where i can call a function every >X milliseconds. How far I am: I wrote an application that checks the ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 42

Thread: software interrupt

  1. Re: software interrupt

    On Sun, 30 Mar 2008 01:21:56 GMT, Ron Eggler wrote:

    >Hi,
    >
    >I would like to write a timer application where i can call a function every
    >X milliseconds. How far I am: I wrote an application that checks the time
    >since the last call and returns 1 when it's "ready" again so i can issue a
    >command like:
    >
    >TimerStart(5); //every 5 seconds
    >while (1){
    > if (CheckTimer(5))
    > cout << "Great, 5 milliseconds have passed" << endl;
    >}
    >
    >This works great but I would like to write something without the while(1)
    >loop where i need to check more often than every 5 milliseconds. I would
    >like something that would jump into a specific function every 5 ms. How can
    >i do something like this? This must work, I remember Delphi 3.0 on Windows
    >had such functionality a long time ago. I'm just not sure how i can write
    >it myself and of course for Linux, not Windows.
    >
    >Thanks!
    >Ron


    The Gtk2 toolkit http://www.gtk.org/ is based on a non-gui object
    system called Glib.

    Glib lets you setup an event-loop program with timers, filehandle
    watching, amoung other things.

    I use the Perl port of Glib, but here is a c version that does what you
    want. While(1) loops can get very complex when you need to do many
    things, or when the completion time of the task is greater than the
    sleep time of the while loop. Anyways, if you want to design for
    expansion and the future, use an event-loop.

    If you return TRUE from the timer callback, it will be
    scheduled to run again. If you return FALSE, it stops.
    Glib can be used with threads too. Also since you
    seem to be using cout, Glib has an C++ extension
    called glibmm, which may be more to your liking.
    Gtk2 has a good maillist too, to help with questions.


    #include
    #include

    GMainLoop* loop;
    int i;

    gboolean callback () {
    printf("%d\n",i );
    i++;

    if( i > 10 ){
    g_main_loop_quit(loop);
    return FALSE;
    }

    return TRUE;
    }


    int main() {

    loop = g_main_loop_new( NULL, TRUE) ;

    g_timeout_add(500, callback, NULL);

    g_main_loop_run(loop);

    return 0;
    }



    zentara


    --
    I'm not really a human, but I play one on earth.
    http://zentara.net/japh.html

  2. Re: software interrupt

    On Sun, 30 Mar 2008 01:21:56 GMT, Ron Eggler wrote:

    >Hi,
    >
    >I would like to write a timer application where i can call a function every
    >X milliseconds. How far I am: I wrote an application that checks the time
    >since the last call and returns 1 when it's "ready" again so i can issue a
    >command like:
    >
    >TimerStart(5); //every 5 seconds
    >while (1){
    > if (CheckTimer(5))
    > cout << "Great, 5 milliseconds have passed" << endl;
    >}
    >
    >This works great but I would like to write something without the while(1)
    >loop where i need to check more often than every 5 milliseconds. I would
    >like something that would jump into a specific function every 5 ms. How can
    >i do something like this? This must work, I remember Delphi 3.0 on Windows
    >had such functionality a long time ago. I'm just not sure how i can write
    >it myself and of course for Linux, not Windows.
    >
    >Thanks!
    >Ron


    The Gtk2 toolkit http://www.gtk.org/ is based on a non-gui object
    system called Glib.

    Glib lets you setup an event-loop program with timers, filehandle
    watching, amoung other things.

    I use the Perl port of Glib, but here is a c version that does what you
    want. While(1) loops can get very complex when you need to do many
    things, or when the completion time of the task is greater than the
    sleep time of the while loop. Anyways, if you want to design for
    expansion and the future, use an event-loop.

    If you return TRUE from the timer callback, it will be
    scheduled to run again. If you return FALSE, it stops.
    Glib can be used with threads too. Also since you
    seem to be using cout, Glib has an C++ extension
    called glibmm, which may be more to your liking.
    Gtk2 has a good maillist too, to help with questions.


    #include
    #include

    GMainLoop* loop;
    int i;

    gboolean callback () {
    printf("%d\n",i );
    i++;

    if( i > 10 ){
    g_main_loop_quit(loop);
    return FALSE;
    }

    return TRUE;
    }


    int main() {

    loop = g_main_loop_new( NULL, TRUE) ;

    g_timeout_add(500, callback, NULL);

    g_main_loop_run(loop);

    return 0;
    }



    zentara


    --
    I'm not really a human, but I play one on earth.
    http://zentara.net/japh.html

  3. Re: software interrupt

    In comp.os.linux.development.system Himanshu Chauhan wrote:
    | phil-news-nospam@ipal.net wrote:
    |
    |>
    |> It is unclear from your posts if your program needs to do something every
    |> 5 milliseconds or every minute. Could you be more specific?
    |>
    |> The mentioned method using setitimer and handling a SIGALRM signal seems
    |> most appropriate to me. You might be able to do all the work needed to
    |> be done inside the signal handler. Or if that work needs to be done in
    |> the main loop, the signal handler could simply do nothing, having let this
    |> wake up some other function your program is waiting in, such as sigsuspend().
    |>
    |
    | Had a similar problem. But SIGALRM and setitimer don't have option for
    | _user data_. Sometimes its important to get the context. Linux kernel
    | typically only delivers the signal that something happened. Sometimes
    | its important to have the context also to know what to do. Currently I
    | do a quick hack, which is start a separate thread that waits for nano
    | seconds and one waking up again performs its task. While creating a
    | thread you can pass it a parameter which can be your context. Any other
    | way of doing this?

    The way to deal with this is to keep a queue of "tasks to do in the future".
    Sort the queue by absolute real time when the tasks need to be done. Each
    time the queue changes, pick the next item from the list and schedule the
    timer event. When the timer event happens, consult the list to see what to
    do. When that task is complete, get the current time and check the list
    again, as there may be more than one task for the same time or nearly the
    same time. If nothing to do for a while, set the timer event for the next
    task, again.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-31-1101@ipal.net |
    |------------------------------------/-------------------------------------|

  4. Re: software interrupt

    In comp.os.linux.development.system Himanshu Chauhan wrote:
    | phil-news-nospam@ipal.net wrote:
    |
    |>
    |> It is unclear from your posts if your program needs to do something every
    |> 5 milliseconds or every minute. Could you be more specific?
    |>
    |> The mentioned method using setitimer and handling a SIGALRM signal seems
    |> most appropriate to me. You might be able to do all the work needed to
    |> be done inside the signal handler. Or if that work needs to be done in
    |> the main loop, the signal handler could simply do nothing, having let this
    |> wake up some other function your program is waiting in, such as sigsuspend().
    |>
    |
    | Had a similar problem. But SIGALRM and setitimer don't have option for
    | _user data_. Sometimes its important to get the context. Linux kernel
    | typically only delivers the signal that something happened. Sometimes
    | its important to have the context also to know what to do. Currently I
    | do a quick hack, which is start a separate thread that waits for nano
    | seconds and one waking up again performs its task. While creating a
    | thread you can pass it a parameter which can be your context. Any other
    | way of doing this?

    The way to deal with this is to keep a queue of "tasks to do in the future".
    Sort the queue by absolute real time when the tasks need to be done. Each
    time the queue changes, pick the next item from the list and schedule the
    timer event. When the timer event happens, consult the list to see what to
    do. When that task is complete, get the current time and check the list
    again, as there may be more than one task for the same time or nearly the
    same time. If nothing to do for a while, set the timer event for the next
    task, again.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-03-31-1101@ipal.net |
    |------------------------------------/-------------------------------------|

  5. Re: software interrupt

    On Mar 31, 9:05*pm, phil-news-nos...@ipal.net wrote:
    > In comp.os.linux.development.system Himanshu Chauhan wrote:| phil-news-nos...@ipal.net wrote:
    >
    > |
    > |>
    > |> It is unclear from your posts if your program needs to do something every
    > |> 5 milliseconds or every minute. *Could you be more specific?
    > |>
    > |> The mentioned method using setitimer and handling a SIGALRM signal seems
    > |> most appropriate to me. *You might be able to do all the work needed to
    > |> be done inside the signal handler. *Or if that work needs to be done in
    > |> the main loop, the signal handler could simply do nothing, having let this
    > |> wake up some other function your program is waiting in, such as sigsuspend().
    > |>
    > |
    > | Had a similar problem. But SIGALRM and setitimer don't have option for
    > | _user data_. Sometimes its important to get the context. Linux kernel
    > | typically only delivers the signal that something happened. Sometimes
    > | its important to have the context also to know what to do. Currently I
    > | do a quick hack, which is start a separate thread that waits for nano
    > | seconds and one waking up again performs its task. While creating a
    > | thread you can pass it a parameter which can be your context. Any other
    > | way of doing this?
    >
    > The way to deal with this is to keep a queue of "tasks to do in the future".
    > Sort the queue by absolute real time when the tasks need to be done. *Each
    > time the queue changes, pick the next item from the list and schedule the
    > timer event. *When the timer event happens, consult the list to see whatto
    > do. *When that task is complete, get the current time and check the list
    > again, as there may be more than one task for the same time or nearly the
    > same time. *If nothing to do for a while, set the timer event for the next
    > task, again.
    >
    > --
    > |---------------------------------------/----------------------------------*|
    > | Phil Howard KA9WGN (ka9wgn.ham.org) */ *Do not send to the address below |
    > | first name lower case at ipal.net * / *spamtrap-2008-03-31-1...@ipal..net |
    > |------------------------------------/-------------------------------------*|




    I think what 'zentara' is suggesting is the straight solution to your
    problem. You can either use glib event loop or you can use select()/
    poll() system calls to implement your user-space timer (ofcourse glib
    uses poll() as an underlying mechanism and you need not do anything).
    You just go through either glib documentation or man page for select()/
    poll().


    Kiran Kumar Mukkamala

  6. Re: software interrupt

    On Mar 31, 9:05*pm, phil-news-nos...@ipal.net wrote:
    > In comp.os.linux.development.system Himanshu Chauhan wrote:| phil-news-nos...@ipal.net wrote:
    >
    > |
    > |>
    > |> It is unclear from your posts if your program needs to do something every
    > |> 5 milliseconds or every minute. *Could you be more specific?
    > |>
    > |> The mentioned method using setitimer and handling a SIGALRM signal seems
    > |> most appropriate to me. *You might be able to do all the work needed to
    > |> be done inside the signal handler. *Or if that work needs to be done in
    > |> the main loop, the signal handler could simply do nothing, having let this
    > |> wake up some other function your program is waiting in, such as sigsuspend().
    > |>
    > |
    > | Had a similar problem. But SIGALRM and setitimer don't have option for
    > | _user data_. Sometimes its important to get the context. Linux kernel
    > | typically only delivers the signal that something happened. Sometimes
    > | its important to have the context also to know what to do. Currently I
    > | do a quick hack, which is start a separate thread that waits for nano
    > | seconds and one waking up again performs its task. While creating a
    > | thread you can pass it a parameter which can be your context. Any other
    > | way of doing this?
    >
    > The way to deal with this is to keep a queue of "tasks to do in the future".
    > Sort the queue by absolute real time when the tasks need to be done. *Each
    > time the queue changes, pick the next item from the list and schedule the
    > timer event. *When the timer event happens, consult the list to see whatto
    > do. *When that task is complete, get the current time and check the list
    > again, as there may be more than one task for the same time or nearly the
    > same time. *If nothing to do for a while, set the timer event for the next
    > task, again.
    >
    > --
    > |---------------------------------------/----------------------------------*|
    > | Phil Howard KA9WGN (ka9wgn.ham.org) */ *Do not send to the address below |
    > | first name lower case at ipal.net * / *spamtrap-2008-03-31-1...@ipal..net |
    > |------------------------------------/-------------------------------------*|




    I think what 'zentara' is suggesting is the straight solution to your
    problem. You can either use glib event loop or you can use select()/
    poll() system calls to implement your user-space timer (ofcourse glib
    uses poll() as an underlying mechanism and you need not do anything).
    You just go through either glib documentation or man page for select()/
    poll().


    Kiran Kumar Mukkamala

  7. Re: software interrupt

    In comp.os.linux.development.system Kiran Kumar Mukkamala wrote:
    | On Mar 31, 9:05?pm, phil-news-nos...@ipal.net wrote:
    |> In comp.os.linux.development.system Himanshu Chauhan wrote:| phil-news-nos...@ipal.net wrote:
    |>
    |> |
    |> |>
    |> |> It is unclear from your posts if your program needs to do something every
    |> |> 5 milliseconds or every minute. ?Could you be more specific?
    |> |>
    |> |> The mentioned method using setitimer and handling a SIGALRM signal seems
    |> |> most appropriate to me. ?You might be able to do all the work needed to
    |> |> be done inside the signal handler. ?Or if that work needs to be done in
    |> |> the main loop, the signal handler could simply do nothing, having let this
    |> |> wake up some other function your program is waiting in, such as sigsuspend().
    |> |>
    |> |
    |> | Had a similar problem. But SIGALRM and setitimer don't have option for
    |> | _user data_. Sometimes its important to get the context. Linux kernel
    |> | typically only delivers the signal that something happened. Sometimes
    |> | its important to have the context also to know what to do. Currently I
    |> | do a quick hack, which is start a separate thread that waits for nano
    |> | seconds and one waking up again performs its task. While creating a
    |> | thread you can pass it a parameter which can be your context. Any other
    |> | way of doing this?
    |>
    |> The way to deal with this is to keep a queue of "tasks to do in the future".
    |> Sort the queue by absolute real time when the tasks need to be done. ?Each
    |> time the queue changes, pick the next item from the list and schedule the
    |> timer event. ?When the timer event happens, consult the list to see what to
    |> do. ?When that task is complete, get the current time and check the list
    |> again, as there may be more than one task for the same time or nearly the
    |> same time. ?If nothing to do for a while, set the timer event for the next
    |> task, again.
    |>
    |> --
    |> |---------------------------------------/----------------------------------?|
    |> | Phil Howard KA9WGN (ka9wgn.ham.org) ?/ ?Do not send to the address below |
    |> | first name lower case at ipal.net ? / ?spamtrap-2008-03-31-1...@ipal.net |
    |> |------------------------------------/-------------------------------------?|
    |
    |
    |
    | I think what 'zentara' is suggesting is the straight solution to your
    | problem. You can either use glib event loop or you can use select()/
    | poll() system calls to implement your user-space timer (ofcourse glib
    | uses poll() as an underlying mechanism and you need not do anything).
    | You just go through either glib documentation or man page for select()/
    | poll().

    If the program is doing lots of computation (100% CPU) or even just busy
    work (a mix of computation and I/O) but needs to periodically do something
    else (output a status of the computation progress, for example), then it
    either needs to be coded to periodically check the time (tracing such a
    program would see lots of time() or gettimeofday() calls) or needs to use an
    alarm/setitimer mechanism to be interrupted when the time comes. His
    concern seemed to be how to deal with more than one different kind of event
    where these events are not necessarily syncronized to each other. What I
    described would handle such cases in lieu of the setitimer having a way to
    pass a tag pointer along to reference the information to distinguish these
    different classes of events.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-04-02-0728@ipal.net |
    |------------------------------------/-------------------------------------|

  8. Re: software interrupt

    In comp.os.linux.development.system Kiran Kumar Mukkamala wrote:
    | On Mar 31, 9:05?pm, phil-news-nos...@ipal.net wrote:
    |> In comp.os.linux.development.system Himanshu Chauhan wrote:| phil-news-nos...@ipal.net wrote:
    |>
    |> |
    |> |>
    |> |> It is unclear from your posts if your program needs to do something every
    |> |> 5 milliseconds or every minute. ?Could you be more specific?
    |> |>
    |> |> The mentioned method using setitimer and handling a SIGALRM signal seems
    |> |> most appropriate to me. ?You might be able to do all the work needed to
    |> |> be done inside the signal handler. ?Or if that work needs to be done in
    |> |> the main loop, the signal handler could simply do nothing, having let this
    |> |> wake up some other function your program is waiting in, such as sigsuspend().
    |> |>
    |> |
    |> | Had a similar problem. But SIGALRM and setitimer don't have option for
    |> | _user data_. Sometimes its important to get the context. Linux kernel
    |> | typically only delivers the signal that something happened. Sometimes
    |> | its important to have the context also to know what to do. Currently I
    |> | do a quick hack, which is start a separate thread that waits for nano
    |> | seconds and one waking up again performs its task. While creating a
    |> | thread you can pass it a parameter which can be your context. Any other
    |> | way of doing this?
    |>
    |> The way to deal with this is to keep a queue of "tasks to do in the future".
    |> Sort the queue by absolute real time when the tasks need to be done. ?Each
    |> time the queue changes, pick the next item from the list and schedule the
    |> timer event. ?When the timer event happens, consult the list to see what to
    |> do. ?When that task is complete, get the current time and check the list
    |> again, as there may be more than one task for the same time or nearly the
    |> same time. ?If nothing to do for a while, set the timer event for the next
    |> task, again.
    |>
    |> --
    |> |---------------------------------------/----------------------------------?|
    |> | Phil Howard KA9WGN (ka9wgn.ham.org) ?/ ?Do not send to the address below |
    |> | first name lower case at ipal.net ? / ?spamtrap-2008-03-31-1...@ipal.net |
    |> |------------------------------------/-------------------------------------?|
    |
    |
    |
    | I think what 'zentara' is suggesting is the straight solution to your
    | problem. You can either use glib event loop or you can use select()/
    | poll() system calls to implement your user-space timer (ofcourse glib
    | uses poll() as an underlying mechanism and you need not do anything).
    | You just go through either glib documentation or man page for select()/
    | poll().

    If the program is doing lots of computation (100% CPU) or even just busy
    work (a mix of computation and I/O) but needs to periodically do something
    else (output a status of the computation progress, for example), then it
    either needs to be coded to periodically check the time (tracing such a
    program would see lots of time() or gettimeofday() calls) or needs to use an
    alarm/setitimer mechanism to be interrupted when the time comes. His
    concern seemed to be how to deal with more than one different kind of event
    where these events are not necessarily syncronized to each other. What I
    described would handle such cases in lieu of the setitimer having a way to
    pass a tag pointer along to reference the information to distinguish these
    different classes of events.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-04-02-0728@ipal.net |
    |------------------------------------/-------------------------------------|

  9. Re: software interrupt

    Himanshu Chauhan writes:

    [...]

    > My problem is not timer. But context. I want to know the
    > context. There can be several timers running in an application each
    > with different timeouts. Without using globals how do you get a
    > context?


    Without storing (a pointer to) 'context information' such that it can
    be accessed without knowing it first, it will not be possible to
    access it. You have correctly observed that. Assuming that you don't
    really care of portability to Linux-systems running 'older kernels'
    and/or C-libraries, POSIX.4 timers appear to be what you are looking
    for: You can specify an arbitrary pointer value as 'timer context' and
    the code accessing it is safely stored in some place where you don't
    need to look at it, lest your religious convictions could be offended.

    Otherwise, the usual course of action would be to implement some sort
    of 'priority queue' (for few timers, a sorted, linked list would be
    sufficient, otherwise, a heap would be a better choice), to program
    an interval timer to fire when the 'next' event is due, to then run
    'events' (by calling callbacks with some per-event void * argument) and
    remove them from the priorty queue until encountering one whose 'time
    to fire' is still in the future (or until there are no more events)
    and then reprogram the interval timer to send the next signal when the
    next 'event' needs to be serviced.

    F'up2 colda.

  10. Re: software interrupt

    Himanshu Chauhan writes:

    [...]

    > My problem is not timer. But context. I want to know the
    > context. There can be several timers running in an application each
    > with different timeouts. Without using globals how do you get a
    > context?


    Without storing (a pointer to) 'context information' such that it can
    be accessed without knowing it first, it will not be possible to
    access it. You have correctly observed that. Assuming that you don't
    really care of portability to Linux-systems running 'older kernels'
    and/or C-libraries, POSIX.4 timers appear to be what you are looking
    for: You can specify an arbitrary pointer value as 'timer context' and
    the code accessing it is safely stored in some place where you don't
    need to look at it, lest your religious convictions could be offended.

    Otherwise, the usual course of action would be to implement some sort
    of 'priority queue' (for few timers, a sorted, linked list would be
    sufficient, otherwise, a heap would be a better choice), to program
    an interval timer to fire when the 'next' event is due, to then run
    'events' (by calling callbacks with some per-event void * argument) and
    remove them from the priorty queue until encountering one whose 'time
    to fire' is still in the future (or until there are no more events)
    and then reprogram the interval timer to send the next signal when the
    next 'event' needs to be serviced.

    F'up2 colda.

  11. Re: software interrupt

    phil-news-nospam@ipal.net wrote:
    > In comp.os.linux.development.system Himanshu Chauhan wrote:
    > | phil-news-nospam@ipal.net wrote:
    > |
    > |>
    > |> It is unclear from your posts if your program needs to do something every
    > |> 5 milliseconds or every minute. Could you be more specific?
    > |>
    > |> The mentioned method using setitimer and handling a SIGALRM signal seems
    > |> most appropriate to me. You might be able to do all the work needed to
    > |> be done inside the signal handler. Or if that work needs to be done in
    > |> the main loop, the signal handler could simply do nothing, having let this
    > |> wake up some other function your program is waiting in, such as sigsuspend().
    > |>
    > |
    > | Had a similar problem. But SIGALRM and setitimer don't have option for
    > | _user data_. Sometimes its important to get the context. Linux kernel
    > | typically only delivers the signal that something happened. Sometimes
    > | its important to have the context also to know what to do. Currently I
    > | do a quick hack, which is start a separate thread that waits for nano
    > | seconds and one waking up again performs its task. While creating a
    > | thread you can pass it a parameter which can be your context. Any other
    > | way of doing this?
    >
    > The way to deal with this is to keep a queue of "tasks to do in the future".
    > Sort the queue by absolute real time when the tasks need to be done. Each
    > time the queue changes, pick the next item from the list and schedule the
    > timer event. When the timer event happens, consult the list to see what to
    > do. When that task is complete, get the current time and check the list
    > again, as there may be more than one task for the same time or nearly the
    > same time. If nothing to do for a while, set the timer event for the next
    > task, again.
    >


    If you think in terms of C++ implementation, then there will be an
    static function that will catch the signal or that will run as a
    seperate thread. Accessing a class can only be done, if there is a
    global holding a class pointer or class pointer passed as a parameter to
    static function. Only to avoid globals I did this _threaded_
    implementation. If you talk about queues, they again have to be global.
    Any work around?

    --Himanshu

  12. Re: software interrupt

    phil-news-nospam@ipal.net wrote:
    > In comp.os.linux.development.system Himanshu Chauhan wrote:
    > | phil-news-nospam@ipal.net wrote:
    > |
    > |>
    > |> It is unclear from your posts if your program needs to do something every
    > |> 5 milliseconds or every minute. Could you be more specific?
    > |>
    > |> The mentioned method using setitimer and handling a SIGALRM signal seems
    > |> most appropriate to me. You might be able to do all the work needed to
    > |> be done inside the signal handler. Or if that work needs to be done in
    > |> the main loop, the signal handler could simply do nothing, having let this
    > |> wake up some other function your program is waiting in, such as sigsuspend().
    > |>
    > |
    > | Had a similar problem. But SIGALRM and setitimer don't have option for
    > | _user data_. Sometimes its important to get the context. Linux kernel
    > | typically only delivers the signal that something happened. Sometimes
    > | its important to have the context also to know what to do. Currently I
    > | do a quick hack, which is start a separate thread that waits for nano
    > | seconds and one waking up again performs its task. While creating a
    > | thread you can pass it a parameter which can be your context. Any other
    > | way of doing this?
    >
    > The way to deal with this is to keep a queue of "tasks to do in the future".
    > Sort the queue by absolute real time when the tasks need to be done. Each
    > time the queue changes, pick the next item from the list and schedule the
    > timer event. When the timer event happens, consult the list to see what to
    > do. When that task is complete, get the current time and check the list
    > again, as there may be more than one task for the same time or nearly the
    > same time. If nothing to do for a while, set the timer event for the next
    > task, again.
    >


    If you think in terms of C++ implementation, then there will be an
    static function that will catch the signal or that will run as a
    seperate thread. Accessing a class can only be done, if there is a
    global holding a class pointer or class pointer passed as a parameter to
    static function. Only to avoid globals I did this _threaded_
    implementation. If you talk about queues, they again have to be global.
    Any work around?

    --Himanshu

  13. Re: software interrupt

    Kiran Kumar Mukkamala wrote:
    > On Mar 31, 9:05 pm, phil-news-nos...@ipal.net wrote:
    >> In comp.os.linux.development.system Himanshu Chauhan wrote:| phil-news-nos...@ipal.net wrote:
    >>
    >> |
    >> |>
    >> |> It is unclear from your posts if your program needs to do something every
    >> |> 5 milliseconds or every minute. Could you be more specific?
    >> |>
    >> |> The mentioned method using setitimer and handling a SIGALRM signal seems
    >> |> most appropriate to me. You might be able to do all the work needed to
    >> |> be done inside the signal handler. Or if that work needs to be done in
    >> |> the main loop, the signal handler could simply do nothing, having let this
    >> |> wake up some other function your program is waiting in, such as sigsuspend().
    >> |>
    >> |
    >> | Had a similar problem. But SIGALRM and setitimer don't have option for
    >> | _user data_. Sometimes its important to get the context. Linux kernel
    >> | typically only delivers the signal that something happened. Sometimes
    >> | its important to have the context also to know what to do. Currently I
    >> | do a quick hack, which is start a separate thread that waits for nano
    >> | seconds and one waking up again performs its task. While creating a
    >> | thread you can pass it a parameter which can be your context. Any other
    >> | way of doing this?
    >>
    >> The way to deal with this is to keep a queue of "tasks to do in the future".
    >> Sort the queue by absolute real time when the tasks need to be done. Each
    >> time the queue changes, pick the next item from the list and schedule the
    >> timer event. When the timer event happens, consult the list to see what to
    >> do. When that task is complete, get the current time and check the list
    >> again, as there may be more than one task for the same time or nearly the
    >> same time. If nothing to do for a while, set the timer event for the next
    >> task, again.
    >>
    >> --
    >> |---------------------------------------/----------------------------------*|
    >> | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    >> | first name lower case at ipal.net / spamtrap-2008-03-31-1...@ipal.net |
    >> |------------------------------------/-------------------------------------*|

    >
    >
    >
    > I think what 'zentara' is suggesting is the straight solution to your
    > problem. You can either use glib event loop or you can use select()/
    > poll() system calls to implement your user-space timer (ofcourse glib
    > uses poll() as an underlying mechanism and you need not do anything).
    > You just go through either glib documentation or man page for select()/
    > poll().
    >
    >
    > Kiran Kumar Mukkamala


    My problem is not timer. But context. I want to know the context. There
    can be several timers running in an application each with different
    timeouts. Without using globals how do you get a context? Timers don't
    have context and from Zentara's code it looks like glib timeout callback
    doesn't have it either!

    --Himanshu

  14. Re: software interrupt

    Kiran Kumar Mukkamala wrote:
    > On Mar 31, 9:05 pm, phil-news-nos...@ipal.net wrote:
    >> In comp.os.linux.development.system Himanshu Chauhan wrote:| phil-news-nos...@ipal.net wrote:
    >>
    >> |
    >> |>
    >> |> It is unclear from your posts if your program needs to do something every
    >> |> 5 milliseconds or every minute. Could you be more specific?
    >> |>
    >> |> The mentioned method using setitimer and handling a SIGALRM signal seems
    >> |> most appropriate to me. You might be able to do all the work needed to
    >> |> be done inside the signal handler. Or if that work needs to be done in
    >> |> the main loop, the signal handler could simply do nothing, having let this
    >> |> wake up some other function your program is waiting in, such as sigsuspend().
    >> |>
    >> |
    >> | Had a similar problem. But SIGALRM and setitimer don't have option for
    >> | _user data_. Sometimes its important to get the context. Linux kernel
    >> | typically only delivers the signal that something happened. Sometimes
    >> | its important to have the context also to know what to do. Currently I
    >> | do a quick hack, which is start a separate thread that waits for nano
    >> | seconds and one waking up again performs its task. While creating a
    >> | thread you can pass it a parameter which can be your context. Any other
    >> | way of doing this?
    >>
    >> The way to deal with this is to keep a queue of "tasks to do in the future".
    >> Sort the queue by absolute real time when the tasks need to be done. Each
    >> time the queue changes, pick the next item from the list and schedule the
    >> timer event. When the timer event happens, consult the list to see what to
    >> do. When that task is complete, get the current time and check the list
    >> again, as there may be more than one task for the same time or nearly the
    >> same time. If nothing to do for a while, set the timer event for the next
    >> task, again.
    >>
    >> --
    >> |---------------------------------------/----------------------------------*|
    >> | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    >> | first name lower case at ipal.net / spamtrap-2008-03-31-1...@ipal.net |
    >> |------------------------------------/-------------------------------------*|

    >
    >
    >
    > I think what 'zentara' is suggesting is the straight solution to your
    > problem. You can either use glib event loop or you can use select()/
    > poll() system calls to implement your user-space timer (ofcourse glib
    > uses poll() as an underlying mechanism and you need not do anything).
    > You just go through either glib documentation or man page for select()/
    > poll().
    >
    >
    > Kiran Kumar Mukkamala


    My problem is not timer. But context. I want to know the context. There
    can be several timers running in an application each with different
    timeouts. Without using globals how do you get a context? Timers don't
    have context and from Zentara's code it looks like glib timeout callback
    doesn't have it either!

    --Himanshu

  15. Re: software interrupt

    >>
    >> I think what 'zentara' is suggesting is the straight solution to your
    >> problem. You can either use glib event loop or you can use select()/
    >> poll() system calls to implement your user-space timer (ofcourse glib
    >> uses poll() as an underlying mechanism and you need not do anything).
    >> You just go through either glib documentation or man page for select()/
    >> poll().
    >>
    >>
    >> Kiran Kumar Mukkamala

    >
    >My problem is not timer. But context. I want to know the context. There
    >can be several timers running in an application each with different
    >timeouts. Without using globals how do you get a context? Timers don't
    >have context and from Zentara's code it looks like glib timeout callback
    >doesn't have it either!
    >
    >--Himanshu


    There are more than timer callbacks allowed in glib. You can do many
    things. Like I said I use Perl, and if you tell me what you really need
    to do with your "context", I could whip up a prototype Perl script to do
    it. Then you could convert it to C. But I have no idea what you mean
    by "needing context".
    You can have filehandle watches, which can be shared between threads.
    You can have multiple threads, each with it's own glib event loop.
    The possibilities are endless.

    It sounds to me like you are looking to run threads. From a thread,
    you cab use g_idle_add to send "context" to the main thread to do
    something.

    Here is some sample code using gtk2 on top of glib (sorry I'm
    really only fluent in Perl, so this is a hack by me and may contain
    C errors if viewed by an expert) :-)

    First is a sender script:
    ##################################################
    #!/usr/bin/perl
    use warnings;
    use strict;
    $|++;
    my $i = 0;
    while(1){
    print "$i\n";
    sleep 1;
    $i++;
    }
    ################################################## ####

    Now a threaded app to watch it, using g_idle_add to communicate
    from the thread to the main thread safely
    compile with:
    gcc -ggdb -ansi -pedantic -W -Wall -O2 -o filename filename.c \
    `pkg-config --cflags --libs gtk+-2.0 gthread-2.0`
    #################################################
    #include
    #include
    #include
    #include
    #include
    #include


    /* good way with idle_add and passing widgets thru structs */
    /* no need for a global widget */

    typedef struct Pdata Pdata;

    struct Pdata {
    GtkButton *button;
    char buffer[20];
    };

    int fileno(FILE *stream);
    FILE *popen(const char *command, const char *mode);

    static void print_something (){
    g_print ("this is the main window thread\n");
    }

    static void destroy (){
    gtk_main_quit ();
    }

    gboolean update (Pdata* data){
    printf("update %s\n", data->buffer);

    /* either way */
    gtk_button_set_label( (GtkButton*) data->button, data->buffer );
    /*
    GtkWidget *button = data->button;
    gtk_button_set_label( button , data->buffer );
    */

    return FALSE;
    }

    void * thread_pipe_socket (GtkButton *button){
    GError *error = G_IO_ERROR_NONE;
    GIOStatus *status;
    gint len;
    GString *buffer = g_string_new ("");
    GIOChannel *channel;
    FILE *foo;
    gchar **new_label;

    /* Declare and define a structure to hold the data. */
    struct Pdata rec;

    /* numbers is a program that generates numbers, sends it to the stdout
    and sleep 1 second. */

    foo = popen ("./numbers", "r");
    channel = g_io_channel_unix_new (fileno (foo));

    if(error){
    g_print("(%i) %s\n", error->code, error->message);
    }

    if (channel != NULL) {
    g_print ("Socket ready\n");
    while (g_io_channel_read_line_string
    (channel, buffer, &len, &error) == G_IO_STATUS_NORMAL){

    new_label = g_strsplit (buffer->str, "\n", -1);
    g_print("%s\n",new_label[0]);

    /* load struct */
    rec.button = button;
    strcpy(rec.buffer, new_label[0] );
    g_idle_add (update, &rec);
    }
    }
    }


    int main (int argc, char *argv[]){

    GtkWidget *window;
    GtkWidget *button;
    pthread_t thread;

    g_thread_init (NULL);

    gtk_init (&argc, &argv);

    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

    g_signal_connect (G_OBJECT (window), "delete_event",
    G_CALLBACK (destroy), NULL);

    g_signal_connect (G_OBJECT (window), "destroy",
    G_CALLBACK (destroy), NULL);

    button = gtk_button_new_with_label ("Main thread talking");

    g_signal_connect (G_OBJECT (button), "clicked",
    G_CALLBACK (print_something), NULL);


    gtk_container_add (GTK_CONTAINER (window), button);

    gtk_widget_show_all (window);

    pthread_create (&thread, NULL, thread_pipe_socket, button);

    gdk_threads_enter ();

    gtk_main ();

    gdk_threads_leave ();

    return 0;
    }
    #############################################














    --
    I'm not really a human, but I play one on earth.
    http://zentara.net/japh.html

  16. Re: software interrupt

    >>
    >> I think what 'zentara' is suggesting is the straight solution to your
    >> problem. You can either use glib event loop or you can use select()/
    >> poll() system calls to implement your user-space timer (ofcourse glib
    >> uses poll() as an underlying mechanism and you need not do anything).
    >> You just go through either glib documentation or man page for select()/
    >> poll().
    >>
    >>
    >> Kiran Kumar Mukkamala

    >
    >My problem is not timer. But context. I want to know the context. There
    >can be several timers running in an application each with different
    >timeouts. Without using globals how do you get a context? Timers don't
    >have context and from Zentara's code it looks like glib timeout callback
    >doesn't have it either!
    >
    >--Himanshu


    There are more than timer callbacks allowed in glib. You can do many
    things. Like I said I use Perl, and if you tell me what you really need
    to do with your "context", I could whip up a prototype Perl script to do
    it. Then you could convert it to C. But I have no idea what you mean
    by "needing context".
    You can have filehandle watches, which can be shared between threads.
    You can have multiple threads, each with it's own glib event loop.
    The possibilities are endless.

    It sounds to me like you are looking to run threads. From a thread,
    you cab use g_idle_add to send "context" to the main thread to do
    something.

    Here is some sample code using gtk2 on top of glib (sorry I'm
    really only fluent in Perl, so this is a hack by me and may contain
    C errors if viewed by an expert) :-)

    First is a sender script:
    ##################################################
    #!/usr/bin/perl
    use warnings;
    use strict;
    $|++;
    my $i = 0;
    while(1){
    print "$i\n";
    sleep 1;
    $i++;
    }
    ################################################## ####

    Now a threaded app to watch it, using g_idle_add to communicate
    from the thread to the main thread safely
    compile with:
    gcc -ggdb -ansi -pedantic -W -Wall -O2 -o filename filename.c \
    `pkg-config --cflags --libs gtk+-2.0 gthread-2.0`
    #################################################
    #include
    #include
    #include
    #include
    #include
    #include


    /* good way with idle_add and passing widgets thru structs */
    /* no need for a global widget */

    typedef struct Pdata Pdata;

    struct Pdata {
    GtkButton *button;
    char buffer[20];
    };

    int fileno(FILE *stream);
    FILE *popen(const char *command, const char *mode);

    static void print_something (){
    g_print ("this is the main window thread\n");
    }

    static void destroy (){
    gtk_main_quit ();
    }

    gboolean update (Pdata* data){
    printf("update %s\n", data->buffer);

    /* either way */
    gtk_button_set_label( (GtkButton*) data->button, data->buffer );
    /*
    GtkWidget *button = data->button;
    gtk_button_set_label( button , data->buffer );
    */

    return FALSE;
    }

    void * thread_pipe_socket (GtkButton *button){
    GError *error = G_IO_ERROR_NONE;
    GIOStatus *status;
    gint len;
    GString *buffer = g_string_new ("");
    GIOChannel *channel;
    FILE *foo;
    gchar **new_label;

    /* Declare and define a structure to hold the data. */
    struct Pdata rec;

    /* numbers is a program that generates numbers, sends it to the stdout
    and sleep 1 second. */

    foo = popen ("./numbers", "r");
    channel = g_io_channel_unix_new (fileno (foo));

    if(error){
    g_print("(%i) %s\n", error->code, error->message);
    }

    if (channel != NULL) {
    g_print ("Socket ready\n");
    while (g_io_channel_read_line_string
    (channel, buffer, &len, &error) == G_IO_STATUS_NORMAL){

    new_label = g_strsplit (buffer->str, "\n", -1);
    g_print("%s\n",new_label[0]);

    /* load struct */
    rec.button = button;
    strcpy(rec.buffer, new_label[0] );
    g_idle_add (update, &rec);
    }
    }
    }


    int main (int argc, char *argv[]){

    GtkWidget *window;
    GtkWidget *button;
    pthread_t thread;

    g_thread_init (NULL);

    gtk_init (&argc, &argv);

    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

    g_signal_connect (G_OBJECT (window), "delete_event",
    G_CALLBACK (destroy), NULL);

    g_signal_connect (G_OBJECT (window), "destroy",
    G_CALLBACK (destroy), NULL);

    button = gtk_button_new_with_label ("Main thread talking");

    g_signal_connect (G_OBJECT (button), "clicked",
    G_CALLBACK (print_something), NULL);


    gtk_container_add (GTK_CONTAINER (window), button);

    gtk_widget_show_all (window);

    pthread_create (&thread, NULL, thread_pipe_socket, button);

    gdk_threads_enter ();

    gtk_main ();

    gdk_threads_leave ();

    return 0;
    }
    #############################################














    --
    I'm not really a human, but I play one on earth.
    http://zentara.net/japh.html

  17. Re: software interrupt

    On Thu, 03 Apr 2008 15:49:57 +0530, Himanshu Chauhan
    wrote:
    >
    >My problem is not timer. But context. I want to know the context. There
    >can be several timers running in an application each with different
    >timeouts. Without using globals how do you get a context? Timers don't
    >have context and from Zentara's code it looks like glib timeout callback
    >doesn't have it either!
    >
    >--Himanshu


    Does this help with context ?
    http://gtk2-perl.sourceforge.net/doc.../MainLoop.html

    where it says
    ################################################## #########3
    Event-driven programs need some sort of loop which watches for events
    and launches the appropriate actions. Glib::MainLoop provides this
    functionality.

    Mainloops have context, provided by the MainContext object. For the most
    part you can use the default context (see default), but if you want to
    create a subcontext for a nested loop which doesn't have the same event
    sources, etc, you can.

    Event sources, attached to main contexts, watch for events to happen,
    and launch appropriate actions. Glib provides a few ready-made event
    sources, the Glib::Timeout, Glib::Idle, and io watch
    (Glib::IO->add_watch).

    Under the hood, Gtk+ adds event sources for GdkEvents to dispatch events
    to your widgets. In fact, Gtk2 provides an abstraction of Glib::MainLoop
    (See Gtk2->main and friends), so you may rarely have cause to use
    Glib::MainLoop directly.

    Note: As of version 1.080, the Glib module uses a custom event source to
    ensure that perl's safe signal handling and the glib polling event loop
    play nicely together. It is no longer necessary to install a timeout to
    ensure that async signals get handled in a timely manner.

    METHODS
    maincontext thingamabob = Glib::MainContext->new
    mainloop = Glib::MainLoop->new ($context=undef, $is_running=FALSE)

    *

    $context (Glib::MainContext thingamabob)
    *

    $is_running (boolean)


    zentara

    --
    I'm not really a human, but I play one on earth.
    http://zentara.net/japh.html

  18. Re: software interrupt

    On Thu, 03 Apr 2008 15:49:57 +0530, Himanshu Chauhan
    wrote:
    >
    >My problem is not timer. But context. I want to know the context. There
    >can be several timers running in an application each with different
    >timeouts. Without using globals how do you get a context? Timers don't
    >have context and from Zentara's code it looks like glib timeout callback
    >doesn't have it either!
    >
    >--Himanshu


    Does this help with context ?
    http://gtk2-perl.sourceforge.net/doc.../MainLoop.html

    where it says
    ################################################## #########3
    Event-driven programs need some sort of loop which watches for events
    and launches the appropriate actions. Glib::MainLoop provides this
    functionality.

    Mainloops have context, provided by the MainContext object. For the most
    part you can use the default context (see default), but if you want to
    create a subcontext for a nested loop which doesn't have the same event
    sources, etc, you can.

    Event sources, attached to main contexts, watch for events to happen,
    and launch appropriate actions. Glib provides a few ready-made event
    sources, the Glib::Timeout, Glib::Idle, and io watch
    (Glib::IO->add_watch).

    Under the hood, Gtk+ adds event sources for GdkEvents to dispatch events
    to your widgets. In fact, Gtk2 provides an abstraction of Glib::MainLoop
    (See Gtk2->main and friends), so you may rarely have cause to use
    Glib::MainLoop directly.

    Note: As of version 1.080, the Glib module uses a custom event source to
    ensure that perl's safe signal handling and the glib polling event loop
    play nicely together. It is no longer necessary to install a timeout to
    ensure that async signals get handled in a timely manner.

    METHODS
    maincontext thingamabob = Glib::MainContext->new
    mainloop = Glib::MainLoop->new ($context=undef, $is_running=FALSE)

    *

    $context (Glib::MainContext thingamabob)
    *

    $is_running (boolean)


    zentara

    --
    I'm not really a human, but I play one on earth.
    http://zentara.net/japh.html

  19. Re: software interrupt

    In comp.os.linux.development.system Himanshu Chauhan wrote:

    | My problem is not timer. But context. I want to know the context. There
    | can be several timers running in an application each with different
    | timeouts. Without using globals how do you get a context? Timers don't
    | have context and from Zentara's code it looks like glib timeout callback
    | doesn't have it either!

    The method I described provides the context. It's just all handled in user
    process space in a priority (by time of next event) queue. The system will
    let you have one timer event active at one time, so it obviously needs to
    be which one is next. A function that keeps the anchor to the event queue
    in its own static variable would be effectively acting as a class. Or use
    an OO language like C++ to do it in OO syntax.

    I've seen this question from people before. I guess I need to write such
    a timer context management function for general use.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-04-03-0912@ipal.net |
    |------------------------------------/-------------------------------------|

  20. Re: software interrupt

    In comp.os.linux.development.system Himanshu Chauhan wrote:

    | My problem is not timer. But context. I want to know the context. There
    | can be several timers running in an application each with different
    | timeouts. Without using globals how do you get a context? Timers don't
    | have context and from Zentara's code it looks like glib timeout callback
    | doesn't have it either!

    The method I described provides the context. It's just all handled in user
    process space in a priority (by time of next event) queue. The system will
    let you have one timer event active at one time, so it obviously needs to
    be which one is next. A function that keeps the anchor to the event queue
    in its own static variable would be effectively acting as a class. Or use
    an OO language like C++ to do it in OO syntax.

    I've seen this question from people before. I guess I need to write such
    a timer context management function for general use.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-04-03-0912@ipal.net |
    |------------------------------------/-------------------------------------|

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast