|
|
|
|
|
|
| Author |
Message |
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
 Posted: Mon Jun 17, 2002 7:44 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
* Mario Sergio Fujikawa Ferreira <lioux@FreeBSD.org> [020613 19:24] wrote:
| Quote: | Hi,
I would like you to review this proposal to add
the socket option SO_NOSIGPIPE: "Do not issue SIGPIPE on EPIPE."
Therefore, we can disable SIGPIPE on a per socket basis instead of
completing ignoring it with either sigpromask(2) or signal(3)
handling.
|
Thanks for taking the time to present this. I'm going to try to
make it an fcntl option instead (so that it can be applied to most
descriptor types.) I should have it committed within a couple of
days.
thanks,
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Mon Jun 17, 2002 7:07 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
Alfred Perlstein wrote:
[ ... ]
Excuse me. Are you in the same discussion I'm in?
Please *read* Mario's patch; specifically:
--- sys/kern/sys_generic.c.orig Mon Feb 25 19:22:18 2002
+++ sys/kern/sys_generic.c Mon Feb 25 19:22:55 2002
@@ -409,7 +409,8 @@
if (auio.uio_resid != cnt && (error == ERESTART ||
error == EINTR || error == EWOULDBLOCK))
error = 0;
- if (error == EPIPE)
+ /* The socket layer handles SIGPIPE */
+ if (error == EPIPE && fp->f_type != DTYPE_SOCKET)
psignal(p, SIGPIPE);
}
cnt -= auio.uio_resid;
Turns off *all* socket-related SIGPIPE as a result of write(2)
and writev(2).
The other part of the patch:
--- sys/kern/uipc_syscalls.c.orig Mon Feb 25 19:59:54 2002
+++ sys/kern/uipc_syscalls.c Mon Feb 25 20:01:48 2002
@@ -586,7 +586,8 @@
if (auio.uio_resid != len && (error == ERESTART ||
error == EINTR || error == EWOULDBLOCK))
error = 0;
- if (error == EPIPE)
+ /* Generation of SIGPIPE can be controlled per socket */
+ if (error == EPIPE && !(so->so_options & SO_NOSIGPIPE))
psignal(p, SIGPIPE);
}
if (error == 0)
Is *only* effective in the send(2), sendto(2), and sendmsg(2)
cases.
In other words, it turns the SIGPIPE off in a code path, makes
it switchable in a second code path, and thereafter provides no
mechanism whereby the SISGPIPE may be turned back on in the first
code path.
The /socket/ is not available in the write path, the /descriptor/
is; to convert it from a /descriptor/ to a /socket/, you would
have to do a lot of tests and dereferencing (nominally OK, since
it's an already expensive error path, but hard to do without
dragging in most of the socket headers into kern/sys_generic.c).
Therefore, my *initial* post in this thread suggested that, if it
be done at all, it be done as a /descriptor/ option, via fcntl,
rather than as a /socket/ option, via setsockopt(). I was not
aware that people has used up all the available fcntl() commands.
Unless you fix the CLEVERLY HIDDEN BREAKAGE it introduces in
dofilewrite() on sockets in sys_generic.c, I think it's a BAD IDEA
to commit the patch.
I *also* think that if this option is set on a listening socket,
that, if it is implemented in this way, it should be inheritted
by each accepted socket. If the bad idea must go forward, it
should at least be implemented correctly.
The obvious reasoning for this is that there is not an fd available
on which to set the option for the new connection until after the
accept(2) is called to accept the connection. Since the *entire*
point of this patch *must* be to save the system call to check to
see if a descriptor is writeable, OR to save the two system calls
that disabling and reenabling the SIGPIPE around a write to close
the tiny check-then-write race window, saving additional system
calls on each socket opened to set the option is also good.
Looking at it from a general standpoint, I'd *still* like to see
some code that people are going to be running on FreeBSD that
won't run without it.
IF the option is committed because of the "compatability" argument,
I'd like to see it named the same thing as at least one other OS,
to avoid "#ifdef FreeBSD"; if that's not going to happen, then you
might as well put better code in the #ifdef FreeBSD", instead.
If I seem to think that this promotes signal semantics that I think
ought to be determined by the system, well, here's Mario's original
rationale for the change in the first place:
| For those that might find it useful, here go a
| simple scenario not easily reproduceable without SO_NOSIGPIPE:
| multi-threaded client, some threads want to handle SIGPIPE,
| others not.
....in other words, to control the threads signal semantics more
closely than is normally permitted by the POSIX definition of
signals.
If I sound like I think this is a slippery slope -- I DO. I can
see *at least* wanting to so the same for any signal that could
result from a "write" that has a default of "terminate process".
I could also see wanting to set the same for SIGURG -- in case
the user establishes a SIGURG handler outside the context of
the library and/or threaded application under discussion. It
is *not* just "terminate process" signal actions that you have
to worry about, it's also any signal whose default action is
"discard signal", and which might have been overridden by the
user.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Mon Jun 17, 2002 6:21 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
Michael Smith wrote:
| Quote: | Shouldn't the framework install its own handler?
How?
|
Before the call, removing it after the call (worst case) or chaining
it (best case).
| Quote: | Oh, please. There's no convention for vector chaining for signal
handlers; I cannot possibly imagine that you're so naive that you can't
immediately see where this scheme falls down.
|
The use of the signals interface in the first place?  .
Order of operation of setting of handlers becomes important; it's
barely manageable to allow replacement of a handler by replacing
a function called by the handler function, instead, and only ever
installing -- never uninstalling -- the handler.
Signals are not really appropriate for transparent use in libraries
anyway.
It's like making system calls directly via "syscall(2)" in threaded
programs. I think that you have to be prepared to do a lot of work
if you insist on using an interface in the wrong context.
| Quote: | Basically, if I have an encapsulation framework, I pretty much
expect it to encapsulate.
This isn't an encapsulation anything. It's just a library. And you
clearly don't grasp the simple nature of either the problem or the
solution.
|
The phrase "seperation of resource ownership" implied encapsulation
for me; sorry for taking it that way, if that's not the way it was
intended.
| Quote: | I guess I'm wondering what software FreeBSD will be able to
run/problems will FreeBSD be able to solve, with this option
present, that it couldn't without the option present?
Have a library open a socket. Have the socket be closed by the remote
end without the application linked with the library not receive a
"surprise" SIGPIPE.
That's it.
|
The SIGPIPE should only occur in the case of a bogus "write",
correct?
In that case, the library should check the writability before
attempting to write, shouldn't it? Or install a SIGPIPE
handler around the call? Or just mask it completely, once,
at library startup (.ctors), and document it as a side effect?
I can see the rationale of wanting to save the two extra system
calls in the case that the library attempts writes without
really caring if the socket still exists at the time of the
attempt.
I guess I'm still wondering what library expects the OS to have
this feature. It seems like it's a really new feature, and
that sofware that really depends on it doesn't exist yet.
What protocol is this for, since TCP returns ECONNRESET, not
EPIPE, anyway?
Thanks,
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Mon Jun 17, 2002 6:13 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
* Michael Smith <msmith@mass.dis.org> [020617 00:51] wrote:
**snip***
Mike, what are you doing??? you should know better by now...
Doesn't the fact that Terry just decided to respond to my post about
SO_NOSIGPIPE (or whatever it's called) with another tirade about
async call gates pretty much make it ABSOFUCKINGLUTLY OBVIOUS that
he's trolling you, me and the rest of the entire project?
Do us all a favor and don't let his trolling wear you down. In the
future just use one of the following "get out a terry thread free"
cards below.
..------.------.------.------.------.
| d | d | d | d | d <
`------`------`------`------`------'
^
tear here -----------------/
then paste into mailer, relief should be immediate.
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Michael Smith
*nix forums beginner
Joined: 14 Jun 2002
Posts: 9
|
| Posted: Mon Jun 17, 2002 5:49 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
| Quote: | Mike, if you haven't removed yourself from avail, then commit
it yourself under SO_whatever, otherwise point me at a handy
delta and I'll do it. If it's just an idea and not in delta
form then I can take a crack at it.
|
Mario already has the diffs, and if they'd been committed last year when
I asked them to be, none of this would be an issue. 8(
= Mike
--
To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is not
only unpatriotic and servile, but is morally treasonable to
the American public. - Theodore Roosevelt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Michael Smith
*nix forums beginner
Joined: 14 Jun 2002
Posts: 9
|
| Posted: Mon Jun 17, 2002 5:47 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
| Quote: | Michael Smith wrote:
This SO_SIGPIPE discussion seems bent on trying to make the signal
facility more able than it is, when in fact signals were (and are)
a bad idea in the first place.
Actually, this has nothing to do with it.
The issue revolves around the seperation of resource ownership between a
program and the frameworks that it links with. In many cases, the
program has no idea that the framework has a pipe/socket open, and is
thus surprised by the signal. In other cases, it will install its own
handler and be confused.
Shouldn't the framework install its own handler?
|
How?
| Quote: | And then, since the old handler is returned in the set call, it
should daisy-chain call the signal handlers, until the default
handler, and not call that one, if other handler are installed.
|
Oh, please. There's no convention for vector chaining for signal
handlers; I cannot possibly imagine that you're so naive that you can't
immediately see where this scheme falls down.
| Quote: | Basically, if I have an encapsulation framework, I pretty much
expect it to encapsulate.
|
This isn't an encapsulation anything. It's just a library. And you
clearly don't grasp the simple nature of either the problem or the
solution.
| Quote: | I'm all for taking stuff back from Darwin; I'd desperately like
FreeBSD to take Darwin's UDF implementation, for example, but
the lack of block devices makes that one impossible. 8-(.
|
That has entirely nothing do with it.
| Quote: | I guess I'm wondering what software FreeBSD will be able to
run/problems will FreeBSD be able to solve, with this option
present, that it couldn't without the option present?
|
Have a library open a socket. Have the socket be closed by the remote
end without the application linked with the library not receive a
"surprise" SIGPIPE.
That's it.
= Mike
--
To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is not
only unpatriotic and servile, but is morally treasonable to
the American public. - Theodore Roosevelt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Mon Jun 17, 2002 5:37 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
Alfred Perlstein wrote:
| Quote: | Whoa, whoa whoa.... :)
Since when does Terry have any input as to what the project is
doing and where it is going?
|
Ditto.
If I were Project Dictator, then the next generation threads would
be implemented with an async call gate, not scheduler activations.
Instead, it uses activations to avoid changing the ABI, even though
the current plan is to add a new call gate in 5.x for the 64 bit
switchover, which is exactly the sort of ABI change that the use of
scheduler activations was trying to avoid. IMO, if it's a new call
gate, it may as well be async... and magically solve a lot of the
hard problems that activations introduced.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Mon Jun 17, 2002 5:31 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
Michael Smith wrote:
| Quote: | This SO_SIGPIPE discussion seems bent on trying to make the signal
facility more able than it is, when in fact signals were (and are)
a bad idea in the first place.
Actually, this has nothing to do with it.
The issue revolves around the seperation of resource ownership between a
program and the frameworks that it links with. In many cases, the
program has no idea that the framework has a pipe/socket open, and is
thus surprised by the signal. In other cases, it will install its own
handler and be confused.
|
Shouldn't the framework install its own handler?
And then, since the old handler is returned in the set call, it
should daisy-chain call the signal handlers, until the default
handler, and not call that one, if other handler are installed.
Basically, if I have an encapsulation framework, I pretty much
expect it to encapsulate.
The problem with SIGPIPE is the same as the problem with SIGCHLD;
it's not really a notification on a descriptor, and if you have a
set of descriptors that might have it on them, then you have to
poll them.
This is one of the reasons it doesn't make sense. You'd have to
be very careful to track which ones had it enabled and disabled,
so that you only polled the ones with it enabled, when you saw it;
even so, you'd have to poll them all, since, like SIGCHLD, getting
the signal doesn't mean that there's only one even that caused the
signal to be raised.
The whole thing is really predicated on either the signals being
queued for delivery (e.g. per POSIX RT signal queueing and Linux
these days), or otherwise being able to treat signals as if they
were real events, rather than just persistant conditions.
If you don't assume queueing (FreeBSD doesn't support it, unless
you capture the signals via kqueue()), then a signal isn't really
an event, and there's really no correspondance with the fd for the
socket for which the signal was raised in th first place.
It's probably beeter to resolve whatever problem with something
other than signals.
| Quote: | Why are you getting SIGPIPE in the first place, rather than
some other indicator? Isn't it because you are using the wrong
system call to send data down a socket?
No, it's because the socket's closed and the signal mask is process-wide.
|
The only place I see this happening in the write path is in
non-AF_INET sockets. It looks like the psignal(SIGPIPE) only
ever happens if underlying code returns EPIPE, which none of
the code in /sys/net or /sys/netinet does (there is one ECONNRESET
in tcp_usrreq.c that is commented with an "/* XXX EPIPE> */").
I see the sosend case, but is the generic version of the routine
used in any of the "struct pr_usrreqs" for anything other than
real pipes (i.e. uipc_usrreqs declaration in uipc_usrreq.c)?
| Quote: | If you are going to provide this facility, at *least* make it
general, and not socket specific. Make it an fcntl, not a
setsockopt.
There aren't any file option bits left.
And when was the last time you got SIGPIPE from a file being closed?
|
Mostly, I get "EPIPE" being set in errno on write returning -1,
and that's for command line things where I've actually used
pipes when building the command.
| Quote: | Sorry Terry, this one's already been solved. The single issue here is
whether FreeBSD actually wants to take something back from Darwin, or
whether you're all just too stubborn and stuck up yourselves to take
what is, in reality, a trivial and entirely worthwhile change.
|
I'm all for taking stuff back from Darwin; I'd desperately like
FreeBSD to take Darwin's UDF implementation, for example, but
the lack of block devices makes that one impossible. 8-(.
| Quote: | So much for "are Apple going to give anything back"? Try "is FreeBSD too
arrogant to accept anything from Apple"?
|
I don't think this is representative of a declaration of war
on "all things Apple". I guess I missed some of the side
discussions you guys had at the recent Usenix conference.
My base assumption, which could be wrong, is that no one would
design new code to rely on signals if they didn't have to, so
the reason for this was to support porting code from a system
that supported the option to FreeBSD.
My question was really pointed at "Is this the only way that
supporting the porting of this code could be safely handled?".
If this is just a feature to have because Linux has it, then
it's a no-brainer (IMO) to say "no", unless someone is using
it, then the answer should be "yes", for ABI compatability.
If there's an application software reason to have it, though,
then the answer *should* be "yes, for API compatability"...
because it's exactly the same argument I've made in the past
in favor of cloning devices being supported in FreeBSD, even
if no one can come up with a problem that absolutely can't be
solved without them.
I guess I'm wondering what software FreeBSD will be able to
run/problems will FreeBSD be able to solve, with this option
present, that it couldn't without the option present?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Mon Jun 17, 2002 4:08 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
* Michael Smith <msmith@mass.dis.org> [020616 22:37] wrote:
| Quote: |
There aren't any file option bits left.
And when was the last time you got SIGPIPE from a file being closed?
Sorry Terry, this one's already been solved. The single issue here is
whether FreeBSD actually wants to take something back from Darwin, or
whether you're all just too stubborn and stuck up yourselves to take
what is, in reality, a trivial and entirely worthwhile change.
So much for "are Apple going to give anything back"? Try "is FreeBSD too
arrogant to accept anything from Apple"?
|
Whoa, whoa whoa.... :)
Since when does Terry have any input as to what the project is
doing and where it is going?
Mike, if you haven't removed yourself from avail, then commit
it yourself under SO_whatever, otherwise point me at a handy
delta and I'll do it. If it's just an idea and not in delta
form then I can take a crack at it.
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Michael Smith
*nix forums beginner
Joined: 14 Jun 2002
Posts: 9
|
| Posted: Fri Jun 14, 2002 8:38 pm Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
| Quote: | This SO_SIGPIPE discussion seems bent on trying to make the signal
facility more able than it is, when in fact signals were (and are)
a bad idea in the first place.
|
Actually, this has nothing to do with it.
The issue revolves around the seperation of resource ownership between a
program and the frameworks that it links with. In many cases, the
program has no idea that the framework has a pipe/socket open, and is
thus surprised by the signal. In other cases, it will install its own
handler and be confused.
| Quote: | Why are you getting SIGPIPE in the first place, rather than
some other indicator? Isn't it because you are using the wrong
system call to send data down a socket?
|
No, it's because the socket's closed and the signal mask is process-wide.
| Quote: | If you are going to provide this facility, at *least* make it
general, and not socket specific. Make it an fcntl, not a
setsockopt.
|
There aren't any file option bits left.
And when was the last time you got SIGPIPE from a file being closed?
Sorry Terry, this one's already been solved. The single issue here is
whether FreeBSD actually wants to take something back from Darwin, or
whether you're all just too stubborn and stuck up yourselves to take
what is, in reality, a trivial and entirely worthwhile change.
So much for "are Apple going to give anything back"? Try "is FreeBSD too
arrogant to accept anything from Apple"?
= Mike
--
To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is not
only unpatriotic and servile, but is morally treasonable to
the American public. - Theodore Roosevelt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Fri Jun 14, 2002 8:10 pm Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
Giorgos Keramidas wrote:
| Quote: | On 2002-06-14 02:48 -0300, Mario Sergio Fujikawa Ferreira wrote:
Darwin call it SOF_NOSIGPIPE because they use it as socket
flag as opposed to a socket option such as either SO_DONTTRUNC or
SO_WANTMORE.
Well, Linux has it as a socket option, it looks okay
as a socket option so the name begins with SO_. SO_NOSIGPIPE
because it describes well its use as it does in Darwin.
However, that's my opinion. I am all open to suggestions.
The example you mentioned above (threaded programs that want to
disable the signal for some of the threads, but not all of them) can
probably be implemented in userland with:
|
[ ... ]
Signal handling in threaded programs is a pain.
Ideally, you would want signals to be queued (i.e. events, rather
than persistent conditions), and you would want them to be
delivered contextually, only to threads that are interested in
them.
This SO_SIGPIPE discussion seems bent on trying to make the signal
facility more able than it is, when in fact signals were (and are)
a bad idea in the first place.
How will this option work with regards to individual threads?
If an individual thread sets this option on an fd, does it set
it on the fd for all threads, or only for the calling thread?
Why are you getting SIGPIPE in the first place, rather than
some other indicator? Isn't it because you are using the wrong
system call to send data down a socket?
Frankly, the signal system is starting to feel like the threads
used by the Lilliputions to tie down Gulliver so that he could
not move. Adding more threads is probably not the right answer.
If you are going to provide this facility, at *least* make it
general, and not socket specific. Make it an fcntl, not a
setsockopt.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Giorgos Keramidas
*nix forums Guru
Joined: 10 May 2002
Posts: 330
|
| Posted: Fri Jun 14, 2002 11:36 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
On 2002-06-14 02:48 -0300, Mario Sergio Fujikawa Ferreira wrote:
| Quote: | Darwin call it SOF_NOSIGPIPE because they use it as socket
flag as opposed to a socket option such as either SO_DONTTRUNC or
SO_WANTMORE.
Well, Linux has it as a socket option, it looks okay
as a socket option so the name begins with SO_. SO_NOSIGPIPE
because it describes well its use as it does in Darwin.
However, that's my opinion. I am all open to suggestions.
|
The example you mentioned above (threaded programs that want to
disable the signal for some of the threads, but not all of them) can
probably be implemented in userland with:
void
sigpipe_handler (int signo)
{
if (we are a thread that needs sigpipe) {
do something;
}
}
One might argue that an option like SO_NOSIGPIPE will be faster and
save all the threads from checking the same thing though, and I will
agree with that. If you give a name to this option though, please
don't make its use depend on a 'double negative'. It would be a lot
better to have this option enabled by default, and call it SO_SIGPIPE.
Then you don't have to "disable a NO_FOO" option, to "enable FOO".
The only option that uses a similar negative meaning right now is
SO_DONTROUTE, while all the rest are of the style "set SO_FOO to
enable behavior bar".
- Giorgos
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Mario Sergio Fujikawa Fer
*nix forums beginner
Joined: 14 Jun 2002
Posts: 4
|
| Posted: Fri Jun 14, 2002 3:48 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
On Thu, Jun 13, 2002 at 10:48:04PM -0400, Garance A Drosihn wrote:
| Quote: | At 11:22 PM -0300 6/13/02, Mario Sergio Fujikawa Ferreira wrote:
Similar options can be found in:
- Darwin - SOF_NOSIGPIPE
- Linux - MSG_NOSIGNAL
- Solaris - Don't recall
- Possibly others
After a very quick check of include files on solaris, nothing obvious
jumps out at me...
How is the proposed SO_NOSIGPIPE different from SOF_NOSIGPIPE or
MSG_NOSIGNAL? If the behavior is meant to be exact the same as
one of those, then should we pick the same name?
|
They all behave the same. Since this is meant to be a socket option,
I prefer SO* to non-standard naming MSG_NOSIGNAL.
Darwin call it SOF_NOSIGPIPE because they use it as socket
flag as opposed to a socket option such as either SO_DONTTRUNC or
SO_WANTMORE.
Well, Linux has it as a socket option, it looks okay
as a socket option so the name begins with SO_. SO_NOSIGPIPE
because it describes well its use as it does in Darwin.
However, that's my opinion. I am all open to suggestions.
--
Mario S F Ferreira - DF - Brazil - "I guess this is a signature."
Computer Science Undergraduate | FreeBSD Committer | CS Developer
flames to beloved devnull@someotherworldbeloworabove.org
feature, n: a documented bug | bug, n: an undocumented feature
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Fri Jun 14, 2002 12:48 am Post subject:
Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
At 11:22 PM -0300 6/13/02, Mario Sergio Fujikawa Ferreira wrote:
| Quote: | Similar options can be found in:
- Darwin - SOF_NOSIGPIPE
- Linux - MSG_NOSIGNAL
- Solaris - Don't recall
- Possibly others
|
After a very quick check of include files on solaris, nothing obvious
jumps out at me...
How is the proposed SO_NOSIGPIPE different from SOF_NOSIGPIPE or
MSG_NOSIGNAL? If the behavior is meant to be exact the same as
one of those, then should we pick the same name?
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Mario Sergio Fujikawa Fer
*nix forums beginner
Joined: 14 Jun 2002
Posts: 4
|
| Posted: Fri Jun 14, 2002 12:22 am Post subject:
Adding SO_NOSIGPIPE to -STABLE/-CURRENT
|
|
|
Hi,
I would like you to review this proposal to add
the socket option SO_NOSIGPIPE: "Do not issue SIGPIPE on EPIPE."
Therefore, we can disable SIGPIPE on a per socket basis instead of
completing ignoring it with either sigpromask(2) or signal(3)
handling.
I can already hear the bikeshed legions crying that this
is not necessary since we can just use one of the aformentioned options.
Furthermore, who might want to handle SIGPIPE? Is it of use?
For those that might find it useful, here go a simple
scenario not easily reproduceable without SO_NOSIGPIPE: multi-threaded
client, some threads want to handle SIGPIPE, others not.
Similar options can be found in:
- Darwin - SOF_NOSIGPIPE
- Linux - MSG_NOSIGNAL
- Solaris - Don't recall
- Possibly others
Do not dimiss this without consideration. This adds
functionality without detracting from our system base. This patch
was written against -STABLE since it's the system I use but should
be easily re-written against -CURRENT.
Credits to whom they are due, original sample code was kindly
provided by Mike Smith <msmith@FreeBSD.org> from Darwin's codebase.
Obtained from: Darwin (msmith sent me darwin's code)
Regards,
ps: Please CC: me since it seems I've not been able to subscribe
to -arch
--
Mario S F Ferreira - DF - Brazil - "I guess this is a signature."
Computer Science Undergraduate | FreeBSD Committer | CS Developer
flames to beloved devnull@someotherworldbeloworabove.org
feature, n: a documented bug | bug, n: an undocumented feature |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 5:41 am | All times are GMT
|
|
Remortgages | Loans | Mobile Phone | Proxy | Bankruptcy
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
