The git issue now has good examples of why something higher-priority and something lower-priority than the current nextTick compromise are desired. As long as not just the higher-priority one is provided, I'll be happy.
On Wednesday, 30 May 2012 15:33:20 UTC+1, Tim Caswell wrote: > > > > On Wed, May 30, 2012 at 4:12 AM, James Howe <[email protected]> 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 >>> >> >
