Hi,
I've some sockets handled through a select() implemented this way:
/ ****************************************
****/
int main(){
.....
fd_set pippo;
....
while(1){
select(maxval+1, &pippo, NULL, NULL, NULL);
if(FD_ISSET(...){
do_this();
if(FD_ISSET(...){
do_that();
}
}
return 0;
}

/ ****************************************
****/

The sockets are the stdin and some ipc sockets... what I would need is
to to setup a timer somewhere in that code to handle a synchronous
action to perform while the select of course is still handling the
asynchronous readings.
I saw some functions like alarm, setitimer, getitimer but I don't know
the usage.. and also I don't know what happens when for instance the
socket receives something and the select triggers it to be read (and
some actions to be performed) while at the same time the timer
expires... who as the right to proceed... is the expiration signal put
to wait until the reading from the select (and following actions)
is(are) done ?

I hope you got what I'm tring to say...
Thanks in advance

RM

[ Post a follow-up to this message ]

InuY4sha wrote:
> Hi,
> I've some sockets handled through a select() implemented this way:
> / ****************************************
****/
> int main(){
> .....
> fd_set pippo;
> ....
>    while(1){
>         select(maxval+1, &pippo, NULL, NULL, NULL);
>         if(FD_ISSET(...){
>             do_this();
>         if(FD_ISSET(...){
>            do_that();
>         }
>   }
> return 0;
> }
>
> / ****************************************
****/
>
> The sockets are the stdin and some ipc sockets... what I would need is
> to to setup a timer somewhere in that code to handle a synchronous
> action to perform while the select of course is still handling the
> asynchronous readings.
> I saw some functions like alarm, setitimer, getitimer but I don't know
> the usage.. and also I don't know what happens when for instance the
> socket receives something and the select triggers it to be read (and
> some actions to be performed) while at the same time the timer
> expires... who as the right to proceed... is the expiration signal put
> to wait until the reading from the select (and following actions)
> is(are) done ?
>
> I hope you got what I'm tring to say...
> Thanks in advance
>
>       RM
>
The last parameter of select is a timer; "man select" tells all about it.

Robert

[ Post a follow-up to this message ]

On 2007-07-27, InuY4sha <riccardomanfrin@gmail.com> wrote:
[...]
> The sockets are the stdin and some ipc sockets... what I would need is
> to to setup a timer somewhere in that code to handle a synchronous
> action to perform while the select of course is still handling the
> asynchronous readings.
[...]

Usually one would use the time-out variable for select and then just
track how much time really elapsed. Normally you'll end up outside of
select either because of some activity on the socket or because the
time-out expired. Before entering select you shall figure out how much
time is left till your synchronious event and set the select time-out.

Better yet, there are libraries out there that allow you to handle
multiple timed events at the same time. Plus provide easier interface to
select. Google for libevent for example.


--
Minds, like parachutes, function best when open

[ Post a follow-up to this message ]

Andrei Voropaev <avorop@mail.ru> writes:
> On 2007-07-27, InuY4sha <riccardomanfrin@gmail.com> wrote:
> [...] 
> [...]
>
> Usually one would use the time-out variable for select and then just
> track how much time really elapsed. Normally you'll end up outside of
> select either because of some activity on the socket or because the
> time-out expired. Before entering select you shall figure out how much
> time is left till your synchronious event and set the select
> time-out.

This doesn't (generally) work, because there is no way to measure
(let alone predict) the time that passed between the timeout
calculation and the actual start of the select processing in the
kernel (and, to mention this at least every once in a while, select
more than twenty years old 'Berkeley UNIX(*)' cruft, the interface is
awful and it is usually the most inefficient way to handle multiple
descriptors within a single thread of control).

[ Post a follow-up to this message ]

On 27 Lug, 16:14, Andrei Voropaev <avo...@mail.ru> wrote:[vbcol=seagreen]
> On 2007-07-27, InuY4sha <riccardomanf...@gmail.com> wrote:
> [...]> The sockets are the stdin and some ipc sockets... what I would 
need is 

thanks, I solved the problem with the select last argument; now what I
would like to know is ... what if I wanted to use timers and alarms ?
is there a good guide to read about this topic?
for instance I'd like to know if ti's possible to have the following
behaviour
 ****************************************
**
set_timer(10);
on_alarm(){
printf("I did other stuff while waiting for the alarm, but now I can
process it even if I'm somewhere else inside my code\n");
}
do_this_while_waiting_alarm();
and_do_that();
...........
 ****************************************
**
PS: sorry for repeating... but as I said this is actually another
question as the previous was answered and with that answer I managed
to do what I needed.

[ Post a follow-up to this message ]

InuY4sha <riccardomanfrin@gmail.com> wrote:
> On 27 Lug, 16:14, Andrei Voropaev <avo...@mail.ru> wrote: 
[vbcol=seagreen]
> thanks, I solved the problem with the select last argument; now what I
> would like to know is ... what if I wanted to use timers and alarms ?
> is there a good guide to read about this topic?
> for instance I'd like to know if ti's possible to have the following
> behaviour
>  ****************************************
**
> set_timer(10);
> on_alarm(){
>   printf("I did other stuff while waiting for the alarm, but now I can
> process it even if I'm somewhere else inside my code\n");
> }
> do_this_while_waiting_alarm();
> and_do_that();
> ...........

Of course. You would first install a handler for the SIGALRM
signal (that doesn't need to do anything, just to have some-
thing that deals with the signal), start a timer using e.g.
getitimer(2) (or just alarm(2) if you don't need more than
second resolution), and then call select(2). If the timer goes
of select(2) will return -1 and errno will be set to EINTR, so
by checking errno you can determine that receiving a signal
was the reason for select(2)s failure. To distinguish between
SIGALRM and other signals you could set some variable within
the signal handler for SIGALRM and test it. So the code will
probably look a bit differently from what you made up above,
but it's not rocket sience;-)
Regards, Jens
--
\   Jens Thoms Toerring  ___      jt@toerring.de
\__________________________      http://toerring.de

[ Post a follow-up to this message ]

On Jul 27, 11:14 pm, InuY4sha <riccardomanf...@gmail.com> wrote:
> On 27 Lug, 16:14, Andrei Voropaev <avo...@mail.ru> wrote:
> 
>
> thanks, I solved the problem with the select last argument; now what I
> would like to know is ... what if I wanted to use timers and alarms ?
> is there a good guide to read about this topic?
> for instance I'd like to know if ti's possible to have the following
> behaviour
>  ****************************************
**
> set_timer(10);
> on_alarm(){
>   printf("I did other stuff while waiting for the alarm, but now I can
> process it even if I'm somewhere else inside my code\n");}
>
> do_this_while_waiting_alarm();
> and_do_that();
> ...........
The most important part you need to read is async signal safe, google
it.

[ Post a follow-up to this message ]

"Rainer Weikusat" <rweikusat@mssgmbh.com> wrote in message
news:876445lw06.fsf@fever.mssgmbh.com...
> Andrei Voropaev <avorop@mail.ru> writes:
[snip] 
>
> This doesn't (generally) work, because there is no way to measure
> (let alone predict) the time that passed between the timeout
> calculation and the actual start of the select processing in the
> kernel

There are several reasons why the "synchronous event" will end up being
handled later than one might naively expect (I can think of three more off
the top of my head), but that isn't necessarily a problem. In fact, I think
it normally isn't.

Alex

[ Post a follow-up to this message ]

"InuY4sha" <riccardomanfrin@gmail.com> wrote in message
news:1185549279.449115.148810@o61g2000hsh.googlegroups.com...
> thanks, I solved the problem with the select last argument; now what I
> would like to know is ... what if I wanted to use timers and alarms ?
> is there a good guide to read about this topic?
> for instance I'd like to know if ti's possible to have the following
> behaviour
>  ****************************************
**
> set_timer(10);
> on_alarm(){
>  printf("I did other stuff while waiting for the alarm, but now I can
> process it even if I'm somewhere else inside my code\n");
> }
> do_this_while_waiting_alarm();
> and_do_that();
> ...........
>  ****************************************
**

The best idea I have found for handling timers and non-blocking I/O in a
single thread is to treat both descriptor readiness and timer expiry as
events. I think libevent (which Andrei Voropaev mentioned) works like this.

The main problem with signals is that you are quite limited in what you can
do in the signal handler, as Bin Chen pointed out, but there is a technique
to turn signals into synchronous events like descriptor readiness: "the
self-pipe trick". The basic idea as I have implemented it goes something
like this:

During initialisation, call pipe() and set both ends non-blocking with
fcntl(). Block signals you are interested in handling. Set up signal
handlers which set a flag to indicate the signal has been delivered and (try
to) write to the write end of the pipe.

In the main loop, check for readability on the read end of the pipe as well
as everything else. Just before you call select()/poll(), unblock the
signals. If the select()/poll() call is interrupted, call again. Block the
signals again. If the pipe is readable, drain it by calling read() until you
get EAGAIN, then check and handle any signal(s), resetting the corresponding
flags.

Alex

[ Post a follow-up to this message ]