Don't fail in TcpStream.flush

[sfackler]

No description provided.

[alexcrichton]

cc @brson, @olsonjeffery

[sfackler]

Libuv doesn't appear to have a flush function for streams, so this should be okay: http://nikhilm.github.io/uvbook/filesystem.html#buffers-and-streams

[alexcrichton]

I'd believe that you don't need to flush, but I defer to those that have worked more in this area.

[anasazi]

I'm fairly sure that libuv doesn't have a notion of 'flush' at all, which makes me wonder whether flush() should be in Writer at all (maybe split it out to a FlushableWriter?). The relevant question here is should we fail for unimplemented behavior or just do nothing? Personally, I'd rather factor it out so it's not even possible to call unimplemented methods. I think I'm going to create a new issue to discuss this in general. We should probably wait on this PR until we have a consensus.

[alexcrichton]

I think the idea of having flush on Writer is fine in my opinion. In my opinion it should just be a no-op if the underlying writer can't be flushed. Things like BufferedWriter do indeed need to be flushed, but if you flush one you should also in theory flush any nested writer it has.

I was mainly concerned that if this were still fail!() to be absolutely certain that uv doesn't have any flushing (which apparently it doesn't).

I can also comment more on the specific issue, but this looks fine to me.

[anasazi]

See discussion on #9126.

[emberian]

@alexcrichton @brson @sfackler I'm a bit concerned with this. When I flush something, I expect to be able to uncleanly terminate immediately and have everything written before the flush actually be written. Is this an unrealistic expectation? What does the flush API actually mean, if it can be a no-op?

[sfackler]

My interpretation is that calling flush guarantees that anything written
before the call is pushed through to the underlying thing. In some
implementations it may be the case that no extra work needs to be done to
guarantee that which is what happens here.
On Sep 15, 2013 3:40 PM, "Corey Richardson" [email protected]
wrote:

@alexcrichton https://github.com/alexcrichton @brsonhttps://github.com/brson
@sfackler https://github.com/sfackler I'm a bit concerned with this.
When I flush something, I expect to be able to uncleanly terminate
immediately and have everything written before the flush actually be
written. Is this an unrealistic expectation? What does the flush API
actually mean, if it can be a no-op?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/9114#issuecomment-24482154
.

[emberian]

Oh, ok. If libuv doesn't require flushing to have it written then I have no
worries.

On Sun, Sep 15, 2013 at 6:43 PM, Steven Fackler [email protected]:

My interpretation is that calling flush guarantees that anything written
before the call is pushed through to the underlying thing. In some
implementations it may be the case that no extra work needs to be done to
guarantee that which is what happens here.
On Sep 15, 2013 3:40 PM, "Corey Richardson" [email protected]
wrote:

@alexcrichton https://github.com/alexcrichton @brson<
https://github.com/brson>
@sfackler https://github.com/sfackler I'm a bit concerned with this.
When I flush something, I expect to be able to uncleanly terminate
immediately and have everything written before the flush actually be
written. Is this an unrealistic expectation? What does the flush API
actually mean, if it can be a no-op?

—
Reply to this email directly or view it on GitHub<
https://github.com/mozilla/rust/pull/9114#issuecomment-24482154>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/9114#issuecomment-24482214
.