[#6548] 1.8.4 p1, warning roundup — Daniel Berger <Daniel.Berger@...>
Hi all,
[#6552] Socket Documentation — zdennis <zdennis@...>
Attached is a patch against the latest socket.c in the ruby_1_8 branch. It covers all Socket
On 11/3/05, zdennis <zdennis@mktec.com> wrote:
Gavin Sinclair wrote:
zdennis wrote:
On 11/9/05, Zach Dennis <zdennis@mktec.com> wrote:
Hi.
[#6558] Method of feeding input to regexp matching — Nikolai Weibull <mailing-lists.ruby-core@...>
I would very much like to be able to provide a Regexp object input from
[#6572] Stack trace consumes information. patch... — Hugh Sasse <hgs@...>
I have just had output like this from rails:
[#6588] Object#clone missing documentation — Eero Saynatkari <ruby-ml@...>
It appears that Object#clone, unlike Object#dup, retains
Hi,
I've attached a documentation patch which tries to address this shortcoming.
Kev Jackson wrote:
[#6602] Re: Unpack Endian Bug — "Berger, Daniel" <Daniel.Berger@...>
> -----Original Message-----
Berger, Daniel wrote:
[#6604] Sandboxing without $SAFE — why the lucky stiff <ruby-core@...>
I've been playing with Ruby sandboxing alot over the past several
[#6619] Wildness: Purpose of NOEX_PUBLIC Flag in rb_add_method? — "Charles E. Thornton" <ruby-core@...>
Several Different references to 'noex'
Charles E. Thornton wrote:
[#6625] Array::fill causes segfaults after many calls — noreply@...
Bugs item #2824, was opened at 2005-11-14 23:11
Hi,
[#6629] Strange error messages using DRb/TupleSpace — Eric Hodel <drbrain@...7.net>
Using
[#6636] alarming changes — "Ara.T.Howard" <ara.t.howard@...>
[#6639] Tuple Class — TRANS <transfire@...>
If I put together a good Tuple class for Ruby could it go into core? I
[#6650] REXML Update Please — zdennis <zdennis@...>
I submitted this as an RCR, but I didn't know that RCR's aren't for the stdlib. Matz commented on
Hi,
Yukihiro Matsumoto wrote:
[#6660] Ruby on Neko ? — Nicolas Cannasse <ncannasse@...>
Hi folks,
Nicolas Cannasse wrote:
Florian Growrote:
Nicolas Cannasse <ncannasse@motion-twin.com> writes:
On Sun, 20 Nov 2005, Christian Neukirchen wrote:
[#6672] testing for hardlink with "test(?-, ...)" flawed on Windows — noreply@...
Bugs item #2858, was opened at 2005-11-20 16:35
Hi,
--- nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
[#6684] semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...>
Hi all,
On Tue, Nov 22, 2005 at 08:22:59AM +0900, Stefan Kaes wrote:
Mauricio Fern疣dez wrote:
On Nov 21, 2005, at 4:37 PM, Stefan Kaes wrote:
Eric Hodel wrote:
Hi,
Yukihiro Matsumoto wrote:
mathew wrote:
Stefan Kaes wrote:
On Tuesday 22 November 2005 12:31, Steven Jenkins wrote:
Hi --
>>>>> "m" == mathew <meta@pobox.com> writes:
Hi,
Yukihiro Matsumoto wrote:
Hi,
Yukihiro Matsumoto wrote:
Hi,
Yukihiro Matsumoto wrote:
On Nov 21, 2005, at 9:37 PM, Stefan Kaes wrote:
Eric Hodel wrote:
URABE Shyouhei wrote:
On Tue, 22 Nov 2005, Stefan Kaes wrote:
Ara.T.Howard wrote:
Hi --
David A. Black wrote:
Hi --
David A. Black wrote:
Hi --
David A. Black wrote:
Hi -
On Tuesday 22 November 2005 15:37, David A. Black wrote:
Hi --
On Tue, 22 Nov 2005, Stefan Kaes wrote:
Mathieu Bouchard wrote:
[#6721] String#index does not work correctly on SuSE10.0 x86_64 — "Kanis, Lars" <Kanis@...>
Hi folks,
[#6798] ruby 1.8.4 preview2 — Yukihiro Matsumoto <matz@...>
Hi,
On Nov 30, 2005, at 8:03 AM, Yukihiro Matsumoto wrote:
>>>>> "E" == Eric Hodel <drbrain@segment7.net> writes:
On Dec 4, 2005, at 4:07 AM, ts wrote:
>>>>> "E" == Eric Hodel <drbrain@segment7.net> writes:
On 11/30/05, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
Yukihiro Matsumoto wrote:
Hi.
[ ruby-Bugs-2872 ] TCPServer should not use SO_REUSEADDR in Cygwin port
Bugs item #2872, was opened at 2005-11-23 11:36
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2872&group_id=426
Category: Standard Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Andrew Wason (awason)
Assigned to: Nobody (None)
Summary: TCPServer should not use SO_REUSEADDR in Cygwin port
Initial Comment:
SO_REUSEADDR behaves strangely under Win32, it allows multiple LISTENs on the same port with indeterminate results. On other platforms SO_REUSEADDR only allows binding to a port not in use or in the TIME_WAIT state.
"This socket option tells the kernel that even if this port is busy (in the TIME_WAIT state), go ahead and reuse it anyway. If it is busy, but with another state, you will still get an address already in use error."
http://www.unixguide.net/network/socketfaq/4.5.shtml
"Once the second sockey has successfully bound, the behvaior for all sockets bound to that port is indeterminate."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_so_reuseaddr_and_so_exclusiveaddruse.asp
In Ruby 1.8.2/1.8.3, ext/socket/socket.c does not set SO_REUSEADDR for TCPServer if _WIN32 is defined, so things work normally in the i386-mswin32 builds. But the i386-cygwin builds do set SO_REUSEADDR and so weird things can happen.
So in socket.c init_inetsock_internal(), this code should also not be compiled for Cygwin (__CYGWIN__):
if (type == INET_SERVER) {
#ifndef _WIN32
status = 1;
setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
(char*)&status, sizeof(status));
#endif
Here is a comparison of current mswin32 and cygwin behaviors:
== Cygwin, 2 process actively listening to same port
$ ruby -v
ruby 1.8.3 (2005-09-21) [i386-cygwin]
# From two different consoles:
$ ruby -rsocket -e 'TCPServer.new("localhost", 3900).accept'
$ ruby -rsocket -e 'TCPServer.new("localhost", 3900).accept'
$ netstat -a -p TCP | grep 3900
TCP jello:3900 jello:0 LISTENING
TCP jello:3900 jello:0 LISTENING
== MSWIN32, 2nd process correctly fails with EADDRINUSE
C:\>ruby -v
ruby 1.8.2 (2004-12-25) [i386-mswin32]
# From two different consoles:
C:\>ruby -rsocket -e 'TCPServer.new("localhost", 3900).accept'
C:\>ruby -rsocket -e 'TCPServer.new("localhost", 3900).accept'
-e:1:in `initialize': Only one usage of each socket address (protocol/network address/port) is normally permitted. - bind(2) (Errno::EADDRINUSE)
from -e:1:in `new'
from -e:1
----------------------------------------------------------------------
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2872&group_id=426