On Wed, May 30, 2012 at 4:12 AM, James Howe <ja...@howeswho.co.uk> wrote:
> Sorry if I'm being obtuse, but why do you need a special API for > Do-Work-After-Run-To-Completion? Can that not be achieved just with normal > program flow-control (i.e. do the work, do the thing after the work, > return)? > No. It's impossible to do anything after returning using normal control-flow. A perfect example is a function that returns an event emitter. The code that attaches event listeners to the emitter *can't* attach listeners till you return the emitter. But there are times that you want to emit events as soon as possible. nextTick tells node to call your function after your caller returns and the whole stack unwinds. > > Further to my assumptions (and experience) about what nextTick does, it > seemed obvious to me that you need to set the handlers before you returned > from the stack to avoid missing data events. Setting them before returning > doesn't cause any problems, as those events can't be processed until you've > returned anyway. > > And to Mikeal, I have quite sizeable projects that would go wrong if > nextTick semantics are changed (and we don't find some way to fix them) but > haven't posted examples because they are a) sizeable, b) closed-source and > c) I don't have time. > Are you cases where you depend on the current implementation of nextTick easy to work around? I know I have tons of code that depends on the current behavior, but in every case I could modify my code to not depend on the behavior. Everyone, please read the thread in the gist that Isaac posted. There are several proposed new APIs that make it possible to do low-priority work that doesn't starve/block the event loop. > > Regards > > > On Wednesday, 30 May 2012 04:21:58 UTC+1, CrabDude wrote: > >> There seem to be 2 considerations: >> >> 1. Adding sameTick() functionality to node. >> 2. Whether nextTick() should house that behavior, or another API / name. >> >> FWIW, I always misunderstood process.nextTick() to occur, as the name >> implies, at the beginning of the next tick. In other words, the name >> implied to me that it would yield to any queued timer / IO events, and then >> execute at the beginning of the next event loop. In fact, b/c of this >> misunderstanding, I found nextTick() and setImmediate() to be eventually >> redundant. >> >> I feel fairly confident in saying that it would be easier for core to >> implement the desired behavior under a different name (sameTick(), etc...) >> and replace all calls to nextTick() with sameTick(), thisTick(), etc..., >> than to change the misperceptions others may have regarding what the >> function name implies, that it in fact actually does not execute until the >> _next_ tick. Changing the behavior of nextTick to something that conflicts >> with its name, would seem to inevitably cause misunderstandings. Core >> obviously (from this thread) though has a different perception of the >> purpose of nextTick, since it seems it has a very specific purpose for >> which it was created and is used. Ironically, those most familiar with its >> *intended purpose* are also those that are most aware that its >> implementation is not always consistent with that purpose. >> >> Is there any reasoning core has regarding why replacing all nextTick() >> calls with thisTick() would be problematic? It is after all new >> functionality, and once again the name nextTick() seems inconsistent with >> its proposed new implementation. >> >> Wouldn't nextTick inevitably be deprecated / replaced by setImmediate >> anyways? It's too bad too, nexTick() is a great name, much nicer than >> "sameTick," "thisTick," etc... >> >> Cheers, >> Adam Crabtree >> >> On Tue, May 29, 2012 at 4:28 PM, Marco Rogers wrote: >> >>> >>>> The problem with this characterization of the API's history is that >>>> it's actually not distinguishable from setTimeout(fn, 0) except in >>>> implementation. As described, they are for quite literally the same thing >>>> although one of them is a little better at it because of an implementation >>>> detail. If this characterization is true (i don't believe it is) then we >>>> should re-purpose or remove nextTick() and improve the performance of >>>> setTimeout(fn,0). I'm not suggesting that is what we do, but it's the >>>> logical conclusion to this characterization. >>>> >>>> >>> This characterization comes from people's real impressions of nextTick. >>> If you want to change that impression, you have some work to do. >>> >>>> >>>> As for whether it's valid to use nextTick or setTimeout or whatever to >>>> break up computation, that's not your call. >>>> >>>> >>>> Are you saying that core can't state the intention of an API? That's >>>> insane. >>>> >>>> Core is free to change the implementation details and semantics of an >>>> API at any time, and has on many occasions. This is always done with the >>>> intention of making it *better*. In order to characterize what is "better" >>>> the API must have a purpose and that has always been dictated by core (Ryan >>>> and then Isaac). >>>> >>> >>> As for the purpose of nextTick, I did agree on what the intended purpose >>> was. And yes you can change whatever you want. You guys are in charge. And >>> we're free to tell you it was a bad idea. You're free to get mad about >>> that. And we're free to tell you you're being kind of bratty about it. >>> Everybody's free! The only problem here is that you think you're allowed to >>> think you're right more than we're allowed to think you're wrong. Strange >>> isn't it? >>> >>> Let me be clear. I think the problem with missing data events should be >>> fixed. But we should evaluate the solutions to make sure they aren't going >>> to cause follow on problems that will haunt us. That's what I'm doing here. >>> If you don't agree about follow on problems, say that. If you don't want to >>> discuss potential follow on problems, say that. If you want to be upset >>> that not everybody who uses node has the exact same view of it's >>> affordances as you do... well I don't know how to help you with that. >>> >>> >>>> Instead, we got a lot of comments about names and about theoretical >>>> breakage in code without anyone noting running code that actually breaks or >>>> is even valid. And now we're being taken down the rabbit hole of "I can't >>>> use this for something it wasn't designed for". >>>> >>>> >>> So since a hand full of people who saw this message and decided to >>> respond don't have concrete use cases in hand ready to go, you can dismiss >>> all concerns? That's crap. We *should* find some use cases, but that >>> doesn't mean the discussion here isn't useful or that we can't reason about >>> what might happen. Reasoning about semantics is how programming works. Or >>> at least that's usually how I do it. >>> >>> The way in which people are providing feedback to this proposed changed >>>> is unproductive because they do not recognize the reality of the current >>>> semantics. >>>> 1) that we cannot remove nextTick() and it is heavily relied on. >>>> 2) that much of the code that *currently* relies on nextTick() breaks >>>> under heavy load because of the current implementation. >>>> >>>> All of this feedback is "me too". It's statements of opinion without >>>> reference the problem that must be solved. >>>> >>> >>> There's some truth to this. As I said, the problem to be solved is >>> important. But pretending it's the only thing that's important and that >>> there isn't potential to cause other problems is ludicrous. Also ludicrous >>> is bullying and yelling at people who came here to discuss things with you >>> in good faith precisely because we care deeply about node and the direction >>> it goes in. Try to get some perspective here man. Also try meditation. >>> >>> >>>> The intention of feedback should be to change the minds of those that >>>> proposed the change, not to prove that your'e right under your terms. >>>> >>> >>> I don't think that's what anyone here has done. I even started out by >>> saying I may need to be educated about this. But I also think you and other >>> core guys are sometimes obtuse and dismissive about how non-core people >>> actually build their mental model about node execution and how that affects >>> the solutions they come up with. I'm not giving you *my* terms. I'm giving >>> you the terms I've gotten from talking to a lot of people who are not node >>> experts. And as much as node benefits from not having the baggage of >>> traditional notions of i/o, it does have the baggage of people's long >>> experience with javascript execution. You can ignore that useful data at >>> your peril. >>> >>> :Marco >>> >>> -- >>> Marco Rogers >>> >>> Life is ten percent what happens to you and ninety percent how you >>> respond to it. >>> - Lou Holtz >>> >> >> >> >> -- >> Better a little with righteousness >> than much gain with injustice. >> Proverbs 16:8 >> > > On Wednesday, 30 May 2012 04:21:58 UTC+1, CrabDude wrote: > >> There seem to be 2 considerations: >> >> 1. Adding sameTick() functionality to node. >> 2. Whether nextTick() should house that behavior, or another API / name. >> >> FWIW, I always misunderstood process.nextTick() to occur, as the name >> implies, at the beginning of the next tick. In other words, the name >> implied to me that it would yield to any queued timer / IO events, and then >> execute at the beginning of the next event loop. In fact, b/c of this >> misunderstanding, I found nextTick() and setImmediate() to be eventually >> redundant. >> >> I feel fairly confident in saying that it would be easier for core to >> implement the desired behavior under a different name (sameTick(), etc...) >> and replace all calls to nextTick() with sameTick(), thisTick(), etc..., >> than to change the misperceptions others may have regarding what the >> function name implies, that it in fact actually does not execute until the >> _next_ tick. Changing the behavior of nextTick to something that conflicts >> with its name, would seem to inevitably cause misunderstandings. Core >> obviously (from this thread) though has a different perception of the >> purpose of nextTick, since it seems it has a very specific purpose for >> which it was created and is used. Ironically, those most familiar with its >> *intended purpose* are also those that are most aware that its >> implementation is not always consistent with that purpose. >> >> Is there any reasoning core has regarding why replacing all nextTick() >> calls with thisTick() would be problematic? It is after all new >> functionality, and once again the name nextTick() seems inconsistent with >> its proposed new implementation. >> >> Wouldn't nextTick inevitably be deprecated / replaced by setImmediate >> anyways? It's too bad too, nexTick() is a great name, much nicer than >> "sameTick," "thisTick," etc... >> >> Cheers, >> Adam Crabtree >> >> On Tue, May 29, 2012 at 4:28 PM, Marco Rogers wrote: >> >>> >>>> The problem with this characterization of the API's history is that >>>> it's actually not distinguishable from setTimeout(fn, 0) except in >>>> implementation. As described, they are for quite literally the same thing >>>> although one of them is a little better at it because of an implementation >>>> detail. If this characterization is true (i don't believe it is) then we >>>> should re-purpose or remove nextTick() and improve the performance of >>>> setTimeout(fn,0). I'm not suggesting that is what we do, but it's the >>>> logical conclusion to this characterization. >>>> >>>> >>> This characterization comes from people's real impressions of nextTick. >>> If you want to change that impression, you have some work to do. >>> >>>> >>>> As for whether it's valid to use nextTick or setTimeout or whatever to >>>> break up computation, that's not your call. >>>> >>>> >>>> Are you saying that core can't state the intention of an API? That's >>>> insane. >>>> >>>> Core is free to change the implementation details and semantics of an >>>> API at any time, and has on many occasions. This is always done with the >>>> intention of making it *better*. In order to characterize what is "better" >>>> the API must have a purpose and that has always been dictated by core (Ryan >>>> and then Isaac). >>>> >>> >>> As for the purpose of nextTick, I did agree on what the intended purpose >>> was. And yes you can change whatever you want. You guys are in charge. And >>> we're free to tell you it was a bad idea. You're free to get mad about >>> that. And we're free to tell you you're being kind of bratty about it. >>> Everybody's free! The only problem here is that you think you're allowed to >>> think you're right more than we're allowed to think you're wrong. Strange >>> isn't it? >>> >>> Let me be clear. I think the problem with missing data events should be >>> fixed. But we should evaluate the solutions to make sure they aren't going >>> to cause follow on problems that will haunt us. That's what I'm doing here. >>> If you don't agree about follow on problems, say that. If you don't want to >>> discuss potential follow on problems, say that. If you want to be upset >>> that not everybody who uses node has the exact same view of it's >>> affordances as you do... well I don't know how to help you with that. >>> >>> >>>> Instead, we got a lot of comments about names and about theoretical >>>> breakage in code without anyone noting running code that actually breaks or >>>> is even valid. And now we're being taken down the rabbit hole of "I can't >>>> use this for something it wasn't designed for". >>>> >>>> >>> So since a hand full of people who saw this message and decided to >>> respond don't have concrete use cases in hand ready to go, you can dismiss >>> all concerns? That's crap. We *should* find some use cases, but that >>> doesn't mean the discussion here isn't useful or that we can't reason about >>> what might happen. Reasoning about semantics is how programming works. Or >>> at least that's usually how I do it. >>> >>> The way in which people are providing feedback to this proposed changed >>>> is unproductive because they do not recognize the reality of the current >>>> semantics. >>>> 1) that we cannot remove nextTick() and it is heavily relied on. >>>> 2) that much of the code that *currently* relies on nextTick() breaks >>>> under heavy load because of the current implementation. >>>> >>>> All of this feedback is "me too". It's statements of opinion without >>>> reference the problem that must be solved. >>>> >>> >>> There's some truth to this. As I said, the problem to be solved is >>> important. But pretending it's the only thing that's important and that >>> there isn't potential to cause other problems is ludicrous. Also ludicrous >>> is bullying and yelling at people who came here to discuss things with you >>> in good faith precisely because we care deeply about node and the direction >>> it goes in. Try to get some perspective here man. Also try meditation. >>> >>> >>>> The intention of feedback should be to change the minds of those that >>>> proposed the change, not to prove that your'e right under your terms. >>>> >>> >>> I don't think that's what anyone here has done. I even started out by >>> saying I may need to be educated about this. But I also think you and other >>> core guys are sometimes obtuse and dismissive about how non-core people >>> actually build their mental model about node execution and how that affects >>> the solutions they come up with. I'm not giving you *my* terms. I'm giving >>> you the terms I've gotten from talking to a lot of people who are not node >>> experts. And as much as node benefits from not having the baggage of >>> traditional notions of i/o, it does have the baggage of people's long >>> experience with javascript execution. You can ignore that useful data at >>> your peril. >>> >>> :Marco >>> >>> -- >>> Marco Rogers >>> >>> Life is ten percent what happens to you and ninety percent how you >>> respond to it. >>> - Lou Holtz >>> >> >> >> >> -- >> Better a little with righteousness >> than much gain with injustice. >> Proverbs 16:8 >> > > On Wednesday, 30 May 2012 04:21:58 UTC+1, CrabDude wrote: > >> There seem to be 2 considerations: >> >> 1. Adding sameTick() functionality to node. >> 2. Whether nextTick() should house that behavior, or another API / name. >> >> FWIW, I always misunderstood process.nextTick() to occur, as the name >> implies, at the beginning of the next tick. In other words, the name >> implied to me that it would yield to any queued timer / IO events, and then >> execute at the beginning of the next event loop. In fact, b/c of this >> misunderstanding, I found nextTick() and setImmediate() to be eventually >> redundant. >> >> I feel fairly confident in saying that it would be easier for core to >> implement the desired behavior under a different name (sameTick(), etc...) >> and replace all calls to nextTick() with sameTick(), thisTick(), etc..., >> than to change the misperceptions others may have regarding what the >> function name implies, that it in fact actually does not execute until the >> _next_ tick. Changing the behavior of nextTick to something that conflicts >> with its name, would seem to inevitably cause misunderstandings. Core >> obviously (from this thread) though has a different perception of the >> purpose of nextTick, since it seems it has a very specific purpose for >> which it was created and is used. Ironically, those most familiar with its >> *intended purpose* are also those that are most aware that its >> implementation is not always consistent with that purpose. >> >> Is there any reasoning core has regarding why replacing all nextTick() >> calls with thisTick() would be problematic? It is after all new >> functionality, and once again the name nextTick() seems inconsistent with >> its proposed new implementation. >> >> Wouldn't nextTick inevitably be deprecated / replaced by setImmediate >> anyways? It's too bad too, nexTick() is a great name, much nicer than >> "sameTick," "thisTick," etc... >> >> Cheers, >> Adam Crabtree >> >> On Tue, May 29, 2012 at 4:28 PM, Marco Rogers wrote: >> >>> >>>> The problem with this characterization of the API's history is that >>>> it's actually not distinguishable from setTimeout(fn, 0) except in >>>> implementation. As described, they are for quite literally the same thing >>>> although one of them is a little better at it because of an implementation >>>> detail. If this characterization is true (i don't believe it is) then we >>>> should re-purpose or remove nextTick() and improve the performance of >>>> setTimeout(fn,0). I'm not suggesting that is what we do, but it's the >>>> logical conclusion to this characterization. >>>> >>>> >>> This characterization comes from people's real impressions of nextTick. >>> If you want to change that impression, you have some work to do. >>> >>>> >>>> As for whether it's valid to use nextTick or setTimeout or whatever to >>>> break up computation, that's not your call. >>>> >>>> >>>> Are you saying that core can't state the intention of an API? That's >>>> insane. >>>> >>>> Core is free to change the implementation details and semantics of an >>>> API at any time, and has on many occasions. This is always done with the >>>> intention of making it *better*. In order to characterize what is "better" >>>> the API must have a purpose and that has always been dictated by core (Ryan >>>> and then Isaac). >>>> >>> >>> As for the purpose of nextTick, I did agree on what the intended purpose >>> was. And yes you can change whatever you want. You guys are in charge. And >>> we're free to tell you it was a bad idea. You're free to get mad about >>> that. And we're free to tell you you're being kind of bratty about it. >>> Everybody's free! The only problem here is that you think you're allowed to >>> think you're right more than we're allowed to think you're wrong. Strange >>> isn't it? >>> >>> Let me be clear. I think the problem with missing data events should be >>> fixed. But we should evaluate the solutions to make sure they aren't going >>> to cause follow on problems that will haunt us. That's what I'm doing here. >>> If you don't agree about follow on problems, say that. If you don't want to >>> discuss potential follow on problems, say that. If you want to be upset >>> that not everybody who uses node has the exact same view of it's >>> affordances as you do... well I don't know how to help you with that. >>> >>> >>>> Instead, we got a lot of comments about names and about theoretical >>>> breakage in code without anyone noting running code that actually breaks or >>>> is even valid. And now we're being taken down the rabbit hole of "I can't >>>> use this for something it wasn't designed for". >>>> >>>> >>> So since a hand full of people who saw this message and decided to >>> respond don't have concrete use cases in hand ready to go, you can dismiss >>> all concerns? That's crap. We *should* find some use cases, but that >>> doesn't mean the discussion here isn't useful or that we can't reason about >>> what might happen. Reasoning about semantics is how programming works. Or >>> at least that's usually how I do it. >>> >>> The way in which people are providing feedback to this proposed changed >>>> is unproductive because they do not recognize the reality of the current >>>> semantics. >>>> 1) that we cannot remove nextTick() and it is heavily relied on. >>>> 2) that much of the code that *currently* relies on nextTick() breaks >>>> under heavy load because of the current implementation. >>>> >>>> All of this feedback is "me too". It's statements of opinion without >>>> reference the problem that must be solved. >>>> >>> >>> There's some truth to this. As I said, the problem to be solved is >>> important. But pretending it's the only thing that's important and that >>> there isn't potential to cause other problems is ludicrous. Also ludicrous >>> is bullying and yelling at people who came here to discuss things with you >>> in good faith precisely because we care deeply about node and the direction >>> it goes in. Try to get some perspective here man. Also try meditation. >>> >>> >>>> The intention of feedback should be to change the minds of those that >>>> proposed the change, not to prove that your'e right under your terms. >>>> >>> >>> I don't think that's what anyone here has done. I even started out by >>> saying I may need to be educated about this. But I also think you and other >>> core guys are sometimes obtuse and dismissive about how non-core people >>> actually build their mental model about node execution and how that affects >>> the solutions they come up with. I'm not giving you *my* terms. I'm giving >>> you the terms I've gotten from talking to a lot of people who are not node >>> experts. And as much as node benefits from not having the baggage of >>> traditional notions of i/o, it does have the baggage of people's long >>> experience with javascript execution. You can ignore that useful data at >>> your peril. >>> >>> :Marco >>> >>> -- >>> Marco Rogers >>> >>> Life is ten percent what happens to you and ninety percent how you >>> respond to it. >>> - Lou Holtz >>> >> >> >> >> -- >> Better a little with righteousness >> than much gain with injustice. >> Proverbs 16:8 >> >
