[#30995] [Bug #3523] win32 exception c0000029 on exit using fibers — B Kelly <redmine@...>

Bug #3523: win32 exception c0000029 on exit using fibers

19 messages 2010/07/02

[#31100] [rubysoc] Queue C-extension patch to come — Ricardo Panaggio <panaggio.ricardo@...>

Hello,

26 messages 2010/07/07
[#31148] Re: [rubysoc] Queue C-extension patch to come — Roger Pack <rogerdpack2@...> 2010/07/09

> As this it my first patch to Ruby, I don't know where to begin with.

[#31320] Re: [rubysoc] Queue C-extension patch to come — Ricardo Panaggio <panaggio.ricardo@...> 2010/07/16

Sorry for leaving this thread for so long. I've tried to finish the

[#31322] Re: [rubysoc] Queue C-extension patch to come — Aaron Patterson <aaron@...> 2010/07/16

On Sat, Jul 17, 2010 at 06:55:35AM +0900, Ricardo Panaggio wrote:

[#31324] Re: [rubysoc] Queue C-extension patch to come — Caleb Clausen <vikkous@...> 2010/07/17

NB: I am Ricardo's mentor for this project.

[#31331] Re: [rubysoc] Queue C-extension patch to come — Benoit Daloze <eregontp@...> 2010/07/17

On 17 July 2010 06:00, Caleb Clausen <vikkous@gmail.com> wrote:

[#31332] Re: [rubysoc] Queue C-extension patch to come — Caleb Clausen <vikkous@...> 2010/07/17

On 7/17/10, Benoit Daloze <eregontp@gmail.com> wrote:

[#31138] Why is there no standard way of creating a String from a char *? — Nikolai Weibull <now@...>

Hi!

14 messages 2010/07/08
[#31146] Re: Why is there no standard way of creating a String from a char *? — Urabe Shyouhei <shyouhei@...> 2010/07/09

(2010/07/09 7:04), Nikolai Weibull wrote:

[#31149] Re: Why is there no standard way of creating a String from a char *? — Nikolai Weibull <now@...> 2010/07/09

On Fri, Jul 9, 2010 at 06:20, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#31150] Re: Why is there no standard way of creating a String from a char *? — Urabe Shyouhei <shyouhei@...> 2010/07/09

(2010/07/09 18:28), Nikolai Weibull wrote:

[#31217] [Bug #3562] regression in respond_to? — Aaron Patterson <redmine@...>

Bug #3562: regression in respond_to?

14 messages 2010/07/12

[#31269] [Bug #3566] memory leak when spawning+joining Threads in a loop — Eric Wong <redmine@...>

Bug #3566: memory leak when spawning+joining Threads in a loop

14 messages 2010/07/13

[#31399] [Backport #3595] Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string — Dreamcat Four <redmine@...>

Backport #3595: Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string

17 messages 2010/07/21

[#31459] [Bug #3607] [trunk/r28731] Gem.path has disappeared? — Ollivier Robert <redmine@...>

Bug #3607: [trunk/r28731] Gem.path has disappeared?

22 messages 2010/07/23

[#31519] [Bug #3622] Net::HTTP does not wait to send request body with Expect: 100-continue — Eric Hodel <redmine@...>

Bug #3622: Net::HTTP does not wait to send request body with Expect: 100-continue

9 messages 2010/07/28

[ruby-core:31071] Re: [Bug #3540] IO.copy_stream fails to detect client disconnect w/sendfile

From: Eric Wong <normalperson@...>
Date: 2010-07-06 08:12:10 UTC
List: ruby-core #31071
Tanaka Akira <akr@fsij.org> wrote:
> 2010/7/6 Eric Wong <normalperson@yhbt.net>:
> 
> > UNIX domain sockets are easy to do notification for since they're always
> > on the same host.  TCP might be harder to detect (and thus the Linux
> > folks choose not to bother at all) because the client is on a different
> > machine and it might lose a physical connection.
> 
> If the kernel cannot detect disconnect, how the kernel causes EPIPE?
> 
> > How does FreeBSD or Solaris behave if a client is on a different machine
> > and has the network cable pulled out?  In the case of physically
> > disconnected network cable, the client TCP stack has no way to notify
> > the server of a disconnect.  "kill -9" or even normal OS shutdown would
> > give the TCP stack a chance to properly shutdown the connection.
> 
> I don't say about such physical disconnection.
> 
> I described about the situation that the kernel knows the connection is
> disconnected.
> 
> The connection is disconnected by RST packet.
> The RST packet is generated by a normal packet is sent to closed port.
> 
>   % ruby -rsocket -e '
>   def netstat
>     s = `netstat -n`
>     s.each_line {|line| puts line if /State\s*$|127.0.0.1:8888/ =~ line }
>     puts
>   end
>   serv = TCPServer.open("127.0.0.1", 8888)
>   s1 = TCPSocket.open("127.0.0.1", 8888)
>   s2 = serv.accept
>   netstat
>   s2.close
>   netstat
>   s1.write "a" rescue p $!
>   netstat
>   s1.write "a" rescue p $!
>   p IO.select(nil, [s1], nil, 0)
>   '
>   Proto Recv-Q Send-Q Local Address           Foreign Address
> State
>   tcp        0      0 127.0.0.1:8888          127.0.0.1:34516
> ESTABLISHED
>   tcp        0      0 127.0.0.1:34516         127.0.0.1:8888
> ESTABLISHED
> 
>   Proto Recv-Q Send-Q Local Address           Foreign Address
> State
>   tcp        0      0 127.0.0.1:8888          127.0.0.1:34516
> FIN_WAIT2
>   tcp        1      0 127.0.0.1:34516         127.0.0.1:8888
> CLOSE_WAIT
> 
>   Proto Recv-Q Send-Q Local Address           Foreign Address
> State
> 
>   #<Errno::EPIPE: Broken pipe>
>   nil
> 
> When first netstat call, the TCP states of
> s1 (the local address is 127.0.0.1:8888) and
> s2 (the local address is 127.0.0.1:34516) are ESTABLISHED.
> 
> s2.close sends a FIN packet to s1.
> s1 receives it and send an ACK packet to s2.
> This changes s1 to FIN_WAIT_2 and s2 to CLOSE_WAIT.
> 
> The first s1.write "a" sends a normal data packet to s2.
> Since the write system call doesn't wait the result of the packet,
> the system call itself succeeds.
> But s2 is CLOSE_WAIT and no data acceptable.
> So s2 sends back a RST packet to s1 and change state of s2 to CLOSED.
> Then s1 receives the RST packet.  It changes the state of s1 to CLOSED.
> 
> The second s1.write "a" fails with EPIPE.
> This is because the kernel knows s1 is CLOSED.
> 
> Now the kernel knows write() for s1 doesn't block.
> (It causes an error immediately)
> So FreeBSD and Solaris notify it with select().
> But Linux doesn't.
> I think it is a problem of Linux.

Ah ok, thanks for the clarification.  I missed the second write failing
with EPIPE entirely :x

I think my second patch to remove "errno = EAGAIN" assignments might be
needed for some corner cases, too, because we need a second write() to
detect EPIPE under Linux.

-- 
Eric Wong

In This Thread