Re: [OT] Interrupting select
"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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
Hi, "Peter T. Breuer" <[EMAIL PROTECTED]> 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 vury 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
Hi, Peter T. Breuer [EMAIL PROTECTED] 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 vury 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
> > [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> ^^
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select
"Mark Hahn wrote:"
> > while (1) {
> > int res = select(n,rfds,wfds,efds,);
> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
"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 vury 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,);
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
> What IS the magic combination that makes select interruptible > by honest-to-goodness non-blocked signals! man [seriously man sigaction] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
"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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Interrupting select.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Interrupting select.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
What IS the magic combination that makes select interruptible by honest-to-goodness non-blocked signals! man [seriously man sigaction] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
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 vury 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Interrupting select.
[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 ^^
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
