Re: [OT] Interrupting select

Re: [OT] Interrupting select

[Peter T. Breuer]

"Mark Hahn wrote:"
> >              while (1) {
> >                  int res = select(n,rfds,wfds,efds,&timeout);
> >                  if (res > 0)
> >                     return res;    // data or error is expected
> >                  if (res == 0) {
> >                     return -ETIME; // timeo in select
> >                  }
> >              }
> > 
> > A resounding "no". kill -9 hurts it but it's invulnerable to everything
> > else.
> 
> um, shouldn't you be testing for res==-1, as well?
> specifically that condition and errno==EINTR is how I'd expect
> signals to effect the loop...

Possibly .. if so that's the answer. But the man page doesn't say so:

          tained in the descriptor sets, which may be zero if the
          timeout expires before anything interesting happens.  On
          error, -1 is returned, and errno is set appropriately;

I assumed that "error" is something like trying to  watch for a
negative number or zero descriptors, or having a fd_set that doesn't
contain open fd's. The reason I assumed that is because EINTR is not
listed as a possible:

    
ERRORS
       EBADF   An invalid file descriptor was given in one of the
               sets.
       EINTR   A non blocked signal was caught.
       EINVAL  n is negative.
       ENOMEM  select was unable to allocate memory for  internal
               tables.

But I'm willing to give it a try! Thanks!

Now back to your regularly scheduled programs ...

Peter

Re: [OT] Interrupting select

[Stephen Wille Padnos]

"Peter T. Breuer" wrote:
[snip]> um, shouldn't you be testing for res==-1, as well?

> > specifically that condition and errno==EINTR is how I'd expect
> > signals to effect the loop...

[snip]

> I assumed that "error" is something like trying to  watch for a
> negative number or zero descriptors, or having a fd_set that doesn't
> contain open fd's. The reason I assumed that is because EINTR is not
> listed as a possible:
>
>
> ERRORS
>        EBADF   An invalid file descriptor was given in one of the
>                sets.
>        EINTR   A non blocked signal was caught.

umm ^^^^^^ - it looks like it's listed here :)

>        EINVAL  n is negative.
>        ENOMEM  select was unable to allocate memory for  internal
>                tables.

[OT] Interrupting select.

[Laramie Leavitt]

I think that this is slightly off-topic, but I figure that
someone here knows the answer or where to point me to the
answer.  Please respond privately so the entire list is not
spamed by the response.

I am writing a threaded network daemon using a thread per
connection model (I know, it is not the most effective, but
I can extend it to use a thread per N connections in the future).
That thread waits on a socket using select, or possibly merely
doing a read.  Messages to be written are inserted into a queue
in shared memory.  I am looking for a way to send the thread a 
signal or event to cause the thread to abort the read or select
call when data is available.

I know that it would be possible to create a unix socket
and write a byte to that socket whenever data is available,
but there should be a simpler message or signal that I can 
send to the thread to accomplish the same thing.

Thanks,
Laramie

Re: [OT] Interrupting select.

[Peter T. Breuer]

"A month of sundays ago Laramie Leavitt wrote:"
> I think that this is slightly off-topic, but I figure that

I'll second this one (waaay off topic for the kernel list,
but ...)

> someone here knows the answer or where to point me to the
> answer.  Please respond privately so the entire list is not
> spamed by the response.

What IS the magic combination that makes select interruptible
by honest-to-goodness non-blocked signals!

> I am writing a threaded network daemon using a thread per
> connection model (I know, it is not the most effective, but

Me TOO.

> in shared memory.  I am looking for a way to send the thread a 
> signal or event to cause the thread to abort the read or select
> call when data is available.

Hear hear.

:-)

(followups to comp.os.linux.system or something like that)


Peter

Re: [OT] Interrupting select.

[Alan Cox]

> What IS the magic combination that makes select interruptible
> by honest-to-goodness non-blocked signals!

man

[seriously man sigaction]

Re: [OT] Interrupting select.

[Peter T. Breuer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UNKNOWN-8BIT, Size: 1862 bytes --]

"A month of sundays ago Alan Cox wrote:"
> > What IS the magic combination that makes select interruptible
> > by honest-to-goodness non-blocked signals!
> man
> 
> [seriously man sigaction]

Equally seriously .. all signals are unblocked in my code and always
have been. The processes receive signals vurrrrry happily. Except when
they are in a select-with-timeout loop, when they keep going round the
loop poking their head out of the select every 5s, and taking no notice
of the murderous hail of die die die die die stuff being slammed at
them.

You can see stuff such as the following early on in my code:

           // handle every s¡ngle signal in one "sighandler"
           for (k = 1; k < 30; k++) {
             struct sigaction sa = { {sighandler}, {{0}}, SA_RESTART, NULL };
             sigfillset(& sa.sa_mask);
             sigaction(k, & sa, NULL);
           }
                                                     
But does select come out of this loop?

             while (1) {
                 int res = select(n,rfds,wfds,efds,&timeout);
                 if (res > 0)
                    return res;    // data or error is expected
                 if (res == 0) {
                    return -ETIME; // timeo in select
                 }
             }

A resounding "no". kill -9 hurts it but it's invulnerable to everything
else.

Looking at the kernel code in select.c. I see it's implemented by poll
(I knew that). sys_select calls do_select and I can't for the life of
me see where anyone sets a signal mask. OTOH if all signals are
masked by default when syscalls are made (I don't know, but it seems
possible) then I can't see where interrupts are allowed again.

The man page for select says nothing about it being interruptible, or
not. 

This has been in the back of my mind for months. I'm glad somebody
asked about it!


Peter

Re: [OT] Interrupting select.

[Alan Cox]

> > [seriously man sigaction]
> Equally seriously .. all signals are unblocked in my code and always
[see man signaction]

>              struct sigaction sa =3D { {sighandler}, {{0}}, SA_RESTART, N=
                                        subtle hint---->      ^^^^^^^^^^
> 

Re: [OT] Interrupting select.

[Olaf Dietsche]

Hi,

"Peter T. Breuer" <ptb@it.uc3m.es> writes:

> "A month of sundays ago Alan Cox wrote:"
> > > What IS the magic combination that makes select interruptible
> > > by honest-to-goodness non-blocked signals!
> > man
> > 
> > [seriously man sigaction]
> 
> Equally seriously .. all signals are unblocked in my code and always
> have been. The processes receive signals vurrrrry happily. Except when
> they are in a select-with-timeout loop, when they keep going round the
> loop poking their head out of the select every 5s, and taking no notice
> of the murderous hail of die die die die die stuff being slammed at
> them.
[snip]
> Looking at the kernel code in select.c. I see it's implemented by poll
> (I knew that). sys_select calls do_select and I can't for the life of
> me see where anyone sets a signal mask. OTOH if all signals are
> masked by default when syscalls are made (I don't know, but it seems
> possible) then I can't see where interrupts are allowed again.
> 
> The man page for select says nothing about it being interruptible, or
> not. 
> 
> This has been in the back of my mind for months. I'm glad somebody
> asked about it!

I'm not really sure, what you're asking for. Select() is interruptible.

But: if you have multiple threads, the signal may be delivered to any
thread. So, what you may see, is, that the signal is delivered to a
thread, but the signaled thread is not the thread waiting in the
select() call.

Therefore it _seems_, as if select() is not interruptible, but it
surely is.

Regards, Olaf.