What is the word for nonblocking coroutine stream stuff?

More gui toolkits than gtk have this concept. In the OI toolkit that I was involved with years ago we had both an idle callback (which is called the next time the system is otherwise idle) as well as a timeout callback (which was called no sooner than N microseconds in the future).
You are basically combining the concept of an idle callback with that of an iterator. Each iteration of loop is one callback. It is very similar to having a sched_yield() function in each interation, only the location of where stuff is done has moved.
Personally, I'd be inclined to call it a work routine and be done with it. I'd call it RenderOneLine or DoSomeWork (or render_one_line or do_some_work if you aren't into the RansomNoteStyleOfFunctionNames).

normal names which aren't quite right: thunk, strategy, policy, template method, callback, cursor, self-updating closure (see STG), hook, continuation, promise.

if you want something suggestive of the action (entering the subroutine for a bit, then yanking back out briefly) and would like to avoid sexual connotations, perhaps "boomerang" or "harpoon" might be good.

though personally, being the animal rights kinda person I am, I'd name it a "hiccup".

The gtk function for doing one iteration of the main loop is called "gtk_main_iteration", that is similar to "iterator" but perhaps more clear in this kind of context.

We had the same problem with terminology when writing the wvdial and tunnel vision libraries - for lack of another word, we called it "going asynchronous."

If you know anything about digital logic system design, there are three main types of circuits: combinational, synchronous sequential, and asynchronous sequential (also known as "fundamental mode").

Synchronous sequential logic circuits do something whenever the clock cycles; asynchronous circuits don't use a clock, but they change immediately in response to a stimulus input, and stop changing once they've finished responding to the stimulus (which usually happens very quickly).

In terms of software, you can imagine that threads start and stop under the control of a clock -- synchronous -- but our callback functions wait for a stimulus (an event happened, or we get an "everyone is idle" message) do something about the stimulus, and then stop when it seems reasonable -- asynchronous.

So amaze your friends: call it an asynchronous sequential callback. Ooh, ah.

Incidentally, when systems like this get relatively large it becomes more and more painful to do this sort of callback stuff properly. Although I call it a "sequential" callback, the code looks anything but sequential -- what used to be a function written in order, from top to bottom, is not a bunch of code fragments in a giant nested "if" or "case" statement. The right way to do this sort of thing is co-operative multitasking, where you call something like schedule() when you want to give up your time slice, and schedule() appears to return when your function gets called again. This is safe from race conditions and avoids the need for semaphores, unlike threads, but is still easy to abuse -- see most Windows 3.x applications for examples of how to screw up co-operative multitasking for everyone.

The next release of Tunnel Vision (and probably wvdial2) are going to use a simple co-operative multitasking system I wrote called WvTask -- yes, it's actually possible to write a portable implementation of this in plain C/C++, using setjmp() and longjmp().

Have fun.

There's a similiar pattern widely used in garbage collection techniques, where instead of pausing the program to wait for the garbage collection to finish, a little bit of the garbage collection is executed each time memory is allocated. This is widely known as "incremental garbage collection", and it is considered valuable since it increases user experience: no more sudden stops of program execution.

So you could name your routine "incremental scanline rendering".

The name of the routine doesn't necessarily have to reflect the technique.

That said, why isn't it an iteration? Yes, there is no fancy underlying data structure, but the point of an iterator is that you get the content you want without having to discover the inner workings. The NextLine() doesn't return anything, sure, but it still does a one-iteration traversal of the data, producing a result. Note that g_list_foreach() doesn't allow for returns, but I would still contend that it iterates over the list. Maybe a "strict" definition of iterator is being applied, but all of these cases satisfy my idea of it.

I kind of like the "asynchronous sequential callback" term. I don't know if that really falls into a technique name properly, but it is a good description of what is happening.

But when it comes down to the function name, I would choose render_one_line(). It describes exactly what is expected from the routine.

I'm not entirely sure which mechanism you're referring to, but in the realtime control industry the single loop control system, where some main loop spends a little time running bits of several jobs to, if not completion, at least a stopping point where they can save state.

You also have "soft interrupts" running more critical stuff in between the tasks in the main loop. These are more like the "event loop" model that Macs use.

I hope I understand correctly what's going on. What your code does seems similar to a relay race in that the state is passed on from one run of the function to the next. So perhaps relay would be a godd name for this technique and your routine could be called art_svp_render_relay.

If i understand your description correctly, what you're talking about is a generator: it's a thing that has some state, and you call it several times in sequence, and each time you call it, it generates some more stuff. Your "lazy list" description exactly fits the word "generator".

Some references to this terminology: in Python, in C++, in Scheme.

For a routine that doesn't produce anything but just does work, the usual term i've seen is "idletask" or "workproc".

I was all ready to cast my hide to the semaphore dogs and suggest "quantum callback"...

However, I really liked the point of the "generator" suggestion. It's an asynchronous state-based generator...which should be familiar to anyone who has studied cellular automata.

So you could condense the concept a bit and call it "celluar callback".

And then, of course, the natural name should be apparent:

bad_driver

Mojotoad (ducking, HHOS)

Actually, I think that the design pattern visitor comes closer to what you are describing. Even though it's not a container, I think the word still applies.

The other possibility is to simply call it scanline hook. I generally use the term "hook" to refer to any callback in a framework, even virtual functions which are meant to be overloaded but don't otherwise do useful work in the base class.

Vistitor sounds interesting...

A few more: ratchet, tiller, evolver (?)...

I like ratchet. It has the taste of a state-based update...the others have a bit of an analog flavor to them.

Mojotoad

...and move on, unblocked and happy.

An iterator is simply a function or process that repetitively repeats an action for each instance of some "thing" until it is out of "things" to work on. It doesn't matter if these "things" are containers, structures or scan lines or whatever.

That seems to be a good definition for what you're doing.

or "incremental renderer", if you prefer.

but as someone pointed out, render_one_line is probably a better name. I'd probably make it into a render_lines(n) instead; you can always get some extra speed out of it if you don't have to update the state struct for each line...

art_svp_render_aa_iter

Thanks to everyone for the suggestions and discussion.

I was just working on a very similar thing in the rproxy library.

Because this is going to go into programs with different IO strategies (threads, nonblocking, blocking) we can make no assumptions on how we'll be called. So, on each call to hs_encode_iter we read in whatever data is available and process it.

The hs_encode_iter function devolves to three internal coroutines, which perform the three encoding functions: generating a whole-file checksum, generating per-block checksums for future matching, and searching for matches with the old file. Each of these has to process independently through the input stream.

I'd just call it a step, but then, being an engineer, I'd rather just get the work done rather whan work out what to call the work function!

Or even "line", since it processes a whole line at a time, right?