the error handling is something domains should do. i haven't tried them
yet, but generally i think it's a good idea to separate error handling from
the business logic. I don't see a good point to let errors bubble up the
pipe, you need to transform them in most cases anyway. but it would be cool
to be trigger a shutdown sequence that bubbles up the pipe.
// in domain
a.pipe(b).pipe(c)
domain.on('error', function(){
a.destroy() //buubles up the chain.
})
every stream could implement the bubbled destroy reaction different,
eighter by destroy self or just unpipe.
Am Mittwoch, 14. August 2013 19:02:19 UTC+2 schrieb Eldar:
>
> Node completely shutdowns because emitter.emit('error') triggers exception
> when there is no listeners for error event.
> The ".pipe()" listens for errors but doesn't change that behavior.
>
> So strictly speaking above server will shutdown on file error because of
> uncaught exception
> and leak on socket hang up, because "close" not an "error" event will be
> emitted.
>
> среда, 14 августа 2013 г., 13:47:14 UTC+4 пользователь Floby написал:
>>
>> file.pipe(res) does clean the resources on error because node completely
>> shuts down, doesn't it?
>>
>> On Tuesday, 13 August 2013 12:08:30 UTC+2, Eldar wrote:
>>>
>>> file.pipe(res)
>>>
>>> On response error (say client clicked close window button) the file will
>>> remain open.
>>> And vice versa on file error response will hang. So the correct way to
>>> pipe is
>>>
>>> file.pipe(res)
>>> file.on('error', res.destroy.bind(res))
>>> res.on('error', file.destroy.bind(res))
>>>
>>> вторник, 13 августа 2013 г., 12:58:09 UTC+4 пользователь Floby написал:
>>>>
>>>> ok.
>>>> I didn't understand the part about " `.pipe()` doesn't cleanup any
>>>> resources.
>>>> Everything works fine until the streaming process completes
>>>> successfully. "
>>>>
>>>> Is there an example where that becomes obvious?
>>>>
>>>> On Monday, 12 August 2013 18:05:02 UTC+2, Eldar wrote:
>>>>>
>>>>> If you want to create some function which accepts a stream and can affect
>>>>> it's state you should be able to destroy the given stream on demand
>>>>> e.g. when something went wrong and/or you are not interested in receiving
>>>>> data anymore.
>>>>> Unfortunately that's impossible with current node readable streams
>>>>> because they:
>>>>>
>>>>> 1. Support multiple consumers
>>>>> 2. Don't have common cleanup interface
>>>>>
>>>>> So you can't touch another's stream because someone else may use it
>>>>> and if you could you don't know how.
>>>>>
>>>>> The absence of ability to pass streams as arguments is a huge flow. You
>>>>> can build almost nothing
>>>>> without that. Now someone may wonder: but there are so many useful
>>>>> modules about streams in npm!?
>>>>> Right. They all rely on `.pipe()`. For some reason all kind of blog
>>>>> posts, tutorials and even node's
>>>>> own documentation teach that for passing readable you can do
>>>>> `readable.pipe(writable)`.
>>>>> E.g. http file server could be:
>>>>>
>>>>> ```javascript
>>>>> var http = require('http')
>>>>> var fs = require('fs')
>>>>> http.createServer(function(req, res) {
>>>>> res.writeHead(200, {'Content-Type': 'text/plain'})
>>>>> fs.createReadStream(req.url.slice(1)).pipe(res)
>>>>> }).listen(3000)
>>>>> ```
>>>>>
>>>>> That's a lie. Exactly for the reasons above `.pipe()` doesn't cleanup any
>>>>> resources.
>>>>> Everything works fine until the streaming process completes successfully.
>>>>> But if something fails you get horrible leaks and hangs.
>>>>> Almost every module doing stream processing have this flow. Obvious or
>>>>> not.
>>>>>
>>>>> That all is sad. We need another, simpler API. Although I believe
>>>>> incompatible changes should be made
>>>>> to node core that is not what I am calling about (at least not at the
>>>>> first place).
>>>>> But we definitely should stop to expose node streams in userland modules,
>>>>> stop to extend "stream base classes", just stop to use it in userland.
>>>>>
>>>>> Now the constructive part. Tim Caswell proposed recently simple-stream
>>>>> <https://github.com/creationix/js-git/blob/master/specs/simple-stream.md>
>>>>> and build many things on top of it.
>>>>>
>>>>> Let's just peek this API as a standard and start using it.
>>>>> Here is readable-to-simple-stream
>>>>> <https://github.com/eldargab/stream-simple> converter which can be used
>>>>> for dealing with node core.
>>>>>
>>>>> It also contains slightly more detailed version of original spec which
>>>>> could be discussed.
>>>>>
>>>>> That's it.
>>>>>
>>>>>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
