2011/12/29 Ulrich Eckhardt dooms...@knuut.de:
On Thursday 29 December 2011 01:20:43 you wrote:
Sorry for the big delay, there are new efforts to try to maintain SDL
packages in better shape.
This bug seems to have been fixed long ago (Thu Apr 20 16:48:25 2006
+, about 9 months before this Debian bug report was submitted), in
this commit upstream:
http://hg.libsdl.org/SDL_net/rev/8551dd6a2235
There is one thing that strikes me though, and that is that I only consider
the fix above as a workaround, not as a fix. There are problems with it:
1. the ignored signal is ignored process-wide
This means that other code which relies on the signal being raised will fail
when libSDL switches the process to ignoring it.
2. the signal is not ignored if a handler is in place
If other areas actually registered a handler, the signal will not be ignored,
the code in SDL checks this. This could mean that SDL then again starts to
fail (I don't think so though).
3. the wrong handler is restored if the signal was ignored
If the calling code ignored the signal process-wide, SDL will not ignore it
again, but when uninitialized it will again switch it to the default, while
the remaining code might still rely on it being ignored.
What I don't get is why send() isn't simply called with MSG_NOSIGNAL as I
suggested. I switched to dropping SDL_net and creating my own network wrapper
doing just that and I never had problems again. I can't provide proper tests
though, since I have abandoned that code altogether.
Sorry, I didn't link the bug report in the previous e-mail, which
sheds more light into this decision:
http://bugzilla.libsdl.org/show_bug.cgi?id=121
As I understand it, Sam Latinga would prefert to use, in order:
1) BSD's SO_NOSIGPIPE socket option, but it's not (was not?) available in Linux;
2) your proposed MSG_NOSIGNAL, which probably it's not (was not?)
available in non-Linux systems;
3) so SIG_IGN is the last resort working portably without complicating
things from his POV, and at that point in time. (Maybe there are
better solutions now?).
As you most probably know, in Debian we have Linux, FreeBSD and GNU
Hurd kernels, so this is a direct concern for us, too.
Althought supporting both options with #ifdefs is probably not much
code and would give the best possible solution in each platform, maybe
the result is inconsistent between systems and the code using SDL_net
would have to forcibly cope with these differences when using
different Unix kernels, so probably he just wanted to abstract
differences away with SDL_net. Probably the majority of projects
using SDL_net favour multiplatformness rather than perfect control
of network conditions, and indeed maybe many of them actually do not
care about Unix differences.
On top of that, today (5+ years after the decision was taken in one
way) changing the behaviour would probably not be good for all people
already relying on this particular behaviour of SDL_net, even if it's
suboptimal.
Does this make sense? What do you think?
Note that I don't object to closing this
bug, as obviously the fix is good enough, but I wanted to raise the concerns
so they are at least documented.
Well, I think that your concern is valid in principle, what I don't
know is if the explanation of upstream's decision changes your
opinion.
Please let me know what do you think about this, now that all the
considerations are taken into account; and let me know if you want me
to escalate this issue to upstream, even if it's only for a suggestion
to take into consideration for their future releases (1.3 is coming
soon, maybe they break more important assumptions/behaviours than this
one).
Cheers.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
