It seems that next tick, when used, always consumes 100% of available CPU. An unexpected drawback, I''m sure. I therefore wish that there were a function similar to next_tick that was still quite frequent but didn''t consume so much CPU. Setting a timer is still only good for up to 200x/sec (so compared to next_tick, that is far slower). So what I wish could be built in future revisions would be something alone the lines of next_time_this_connections_state_changes_somehow(execute_this) i.e. when their backpressure changes at all, you''d execute the block. Then you wouldn''t need to poll so much (as anything does, using next_tick), and you could still keep excellent control of your stacks as the pressure changes. Just my thought for the day. Cheers! -Roger
On Nov 12, 2007 6:55 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> It seems that next tick, when used, always consumes 100% of available > CPU. An unexpected drawback, I''m sure. > > I therefore wish that there were a function similar to next_tick that > was still quite frequent but didn''t consume so much CPU. Setting a > timer is still only good for up to 200x/sec (so compared to next_tick, > that is far slower). > > So what I wish could be built in future revisions would be something > alone the lines of > next_time_this_connections_state_changes_somehow(execute_this) > i.e. when their backpressure changes at all, you''d execute the block. > Then you wouldn''t need to poll so much (as anything does, using > next_tick), and you could still keep excellent control of your stacks > as the pressure changes.Not quite sure what you''re actually trying to do here. next_tick will certainly busy-loop if nothing else is happening in the application. Are you waiting for an outbound connection to drain?
>Not quite sure what you''re actually trying to do here. next_tick >will >certainly busy-loop if nothing else is happening in the application. >Are you waiting for an outbound connection to drain?Yeah similar to FileStreamer I want to keep tight tabs on the outbound queues. I think the answer for now is to just use periodic_timer and call it good. Question: should period timer warn when a user enters a time less than the set quantum? Do you want me to add that?
On Nov 12, 2007 7:57 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> >Not quite sure what you''re actually trying to do here. next_tick >will > >certainly busy-loop if nothing else is happening in the application. > >Are you waiting for an outbound connection to drain? > > Yeah similar to FileStreamer I want to keep tight tabs on the outbound > queues. I think the answer for now is to just use periodic_timer and > call it good. >This is a pretty interesting question, actually. I haven''t hit busy-loop problems with #next_tick in this kind of application because I usually schedule the next data to send on #next_tick only if the outbound buffer of a connection is above a certain amount (like a megabyte, for example). Since the kernel will be eating up the outbound data in the background, some work is generally being done all the time. Are you doing this a different way?> Question: should period timer warn when a user enters a time less than > the set quantum? Do you want me to add that?I don''t like having it throw an exception but I can''t think of a better way to do it.
> > >Not quite sure what you''re actually trying to do here. next_tick >will > > >certainly busy-loop if nothing else is happening in the application. > > >Are you waiting for an outbound connection to drain? > > > > Yeah similar to FileStreamer I want to keep tight tabs on the outbound > > queues. I think the answer for now is to just use periodic_timer and > > call it good. > > > This is a pretty interesting question, actually. I haven''t hit > busy-loop problems with #next_tick in this kind of application because > I usually schedule the next data to send on #next_tick only if the > outbound buffer of a connection is above a certain amount (like a > megabyte, for example). Since the kernel will be eating up the > outbound data in the background, some work is generally being done all > the time.Ahh so you basically only respond to ''normal'' EM events, like receive_data, and schedule one-timers to occur using next_tick. So using next_tick in a loop might not be advised. I put some warnings of this on the NextTick wiki page.> > Question: should period timer warn when a user enters a time less than > > the set quantum? Do you want me to add that? > > I don''t like having it throw an exception but I can''t think of a > better way to do it.You could output to stdout a warning message. -- -Roger Pack For God hath not given us the spirit of fear; but of power, and of love, and of a sound mind" -- 2 Timothy 1:7