On Mon, 19 Feb 2007, Amos Shapira wrote:
Or the timer expires and makes the waiter do some test and repeat job,
which falls under my definition of busy wait (even if it gets to rest for
a while between iterations).
The wait consists in yielding. The process spends user time only while
not
I did not understand the current problem, however, just giving my 2c blindly
so...:
1. Internet sockets using tcp protocol is the same as using select with a
timeout since this is what the tcp protocol is doing. Timeouts.
2. Can't all this discussion be solved by simply reading the /proc
On Mon, 19 Feb 2007, Tzahi Fadida wrote:
I did not understand the current problem, however, just giving my 2c blindly
so...:
1. Internet sockets using tcp protocol is the same as using select with a
timeout since this is what the tcp protocol is doing. Timeouts.
No. The internet sockets have
On Mon, 19 Feb 2007, Tzahi Fadida wrote:
Essentially you are right that poking a system to see if it is alive can bite
your hand.
I wonder if there is a FOSS event engine out there aside from the one i know
from IBM.
Check out 'watcher' by kenneth ingham. It has a different purpose but it
On 20/02/07, Peter [EMAIL PROTECTED] wrote:
Huh?? When a group leader exits his parent gets SIGCHLD. That's one of
those
sticky PITA's of UNIX process programming. (I've just double-checked
this
with a quick program which demonstrate it). The only way I can remember
to
avoid receving
Which pid? The child may very well have forked and exited so the parent is
actually talking to its grand-children, it could also be that multiple
processes are sharing the same socketpair on the other side (that's another
contingency I'll have to take care of).
Then again - if the socketpair()
On 20/02/07, Peter [EMAIL PROTECTED] wrote:
See:
http://www.erlenstar.demon.co.uk/unix/faq_2.html
1.1) last 2 paragraphs and 1.6), 1.7) . Note the part about 'not
confusing inetd' at the end of 1.7). This is almost the problem you
have.
(rest deleted for brevity).
OK, I give up trying
On Tue, 20 Feb 2007, Amos Shapira wrote:
You are getting off subject - the original question was about how to find
out that the other side of a socketpair has closed it.
There is none. That's the point. You can monitor the pid to see if it
went away. Worse if the process becomes a zombie
On 20/02/07, Peter [EMAIL PROTECTED] wrote:
Maybe I did not get the question. We seem to be talking past each other.
Just read the thread again from the absolute beginning, including the
subject line...
--Amos
Baruch Even wrote:
You want to avoid another case of race condition.
I think Amos intended to simply call exit from the signal handler, so
that problem would not be an issue. However:
Without a select you will have code like:
handle_sigchld() { dead_child=1; wait(); }
dorecv() {
On Sun, 18 Feb 2007, Amos Shapira wrote:
That's why you must use both a reaper and select() with timeout.
What's the point of select(2) with a timeout? How long should the timeout be
set and what should be checked when it's reached? Why wouldn't a child
reaper be enough in the situation
On 18/02/07, Shachar Shemesh [EMAIL PROTECTED] wrote:
Baruch Even wrote:
You want to avoid another case of race condition.
I think Amos intended to simply call exit from the signal handler, so
that problem would not be an issue. However:
Indeed.
Without a select you will have code like:
On 18/02/07, Peter [EMAIL PROTECTED] wrote:
On Sun, 18 Feb 2007, Amos Shapira wrote:
That's why you must use both a reaper and select() with timeout.
What's the point of select(2) with a timeout? How long should the
timeout be
set and what should be checked when it's reached? Why wouldn't
On 16/02/07, Shachar Shemesh [EMAIL PROTECTED] wrote:
Baruch Even wrote:
If it is a process parent/child pair then you could listen on the signal
SIGCHLD and when the child exits your process will be notified by the
kernel.
Well, no.
The most obvious programs that will be run through
On 16/02/07, Tzahi Fadida [EMAIL PROTECTED] wrote:
Is there an added value in contrast of just using a simple
server that accepts on low ports but bounces the packets
to a low privileged port?
Examples:
1. A daemon for which you don't have the source and which you can't
configure to use
On 17/02/07, Peter [EMAIL PROTECTED] wrote:
On Fri, 16 Feb 2007, Baruch Even wrote:
You assume that the signal was received in the recv() call, you'll have
a race condition where a child might die just before you go into recv()
and the child is never reaped. The chance might be small to
* Amos Shapira [EMAIL PROTECTED] [070218 05:18]:
On 17/02/07, Peter [EMAIL PROTECTED] wrote:
On Fri, 16 Feb 2007, Baruch Even wrote:
You assume that the signal was received in the recv() call, you'll have
a race condition where a child might die just before you go into recv()
and the
Tzahi Fadida wrote:
On Friday 16 February 2007 03:07, you wrote:
Hi,
I'm trying to help complete Shachar Shemesh' privbind project (
http://sourceforge.net/projects/privbind) and it mostly works except that
Just from curiosity, what does it mean privileged socket? why are they
* Shachar Shemesh [EMAIL PROTECTED] [070216 12:10]:
Baruch Even wrote:
If it is a process parent/child pair then you could listen on the signal
SIGCHLD and when the child exits your process will be notified by the
kernel.
Well, no.
The most obvious programs that will be run through
Is there an added value in contrast of just using a simple
server that accepts on low ports but bounces the packets
to a low privileged port?
Also, again of curiosity :), is there a way to wrap the daemon
without forking and replacing the bind call with a customized bind
with a more detailed
On Fri, 16 Feb 2007, Amos Shapira wrote:
Digging a bit more in the kernel source I see that since the SOCK_DGRAM
sockets are not connected, closing one side won't bother to inform the other
side about the shutdown. Switching to SOCK_SEQPACKET solved the problem.
This means that privbind will
On Fri, 16 Feb 2007, Baruch Even wrote:
You assume that the signal was received in the recv() call, you'll have
a race condition where a child might die just before you go into recv()
and the child is never reaped. The chance might be small to miniscule
but it's still there.
That's why you
On Fri, 16 Feb 2007, Tzahi Fadida wrote:
Is there an added value in contrast of just using a simple
server that accepts on low ports but bounces the packets
to a low privileged port?
The easy way to do this was discussed before, it's called port
forwarding. It's done at the firewall level.
Hi,
I'm trying to help complete Shachar Shemesh' privbind project (
http://sourceforge.net/projects/privbind) and it mostly works except that
when the writing side of the socketpair exits, the side which calls
recvfrom keeps waiting for messages.
I couldn't find anything which suggests that I'm
24 matches
Mail list logo
