Queue status discussion (was #7 on bug)

[Henner Zeller]

Hi,

Leonardo wrote on https://github.com/hzeller/beagleg/issues/7

On 5 October 2016 at 02:31, lromor <notifi...@github.com> wrote:

Ok, So now we have the core functionality of update-status, Now we should wire up it to the actual gcode command as Henner pointed out.

In the wiring process are we going to remove the blocking wait for the PRU to free a slot?
In this way we could avoid freezing beagleg when the queue is full.

Also, It should be time to decide whether or not we want the UDP server.

Let's discuss this on the mailing list because it is less annoying than the bugtracker.

Alright, some thoughts:

  - you can remove the blocking wait by hooking it up to the central select(). Right now, the select resides in the gcode parser, so a first step would be to pull it out of there and put somewhere more close to main().

  - The blocking call between the host and CPU is just a filedescriptor being waited on afaik, so it should be possible to do via select(). Whenever that file-descriptor returns, we should execute whatever is needed to stuff more things in the queue. Typically, the blocking wait is there, because we had this one item that we were processing that didn't fit anymore.

 - For the above, we should make an abstraction in which a std::function<void()> is called whenever a filedescriptor is ready. That way, we can just give it a closure that does the 'move more stuff into the queue'.

  - the gcode parser thing should stop processing rows while there is this thing we waiting on to be processed (as it is now with the blocking call, but now it explicitly needs to not accept new data until that condition is met, e.g. by unregistering itself from the select)

  - To prevent underruns and a little bit more pre-procssed things, we can have a larger host-based queue that has prepared items to be put in the PRU queue. That way we can have more than one thing to be waiting on, and the gcode parser can operate a bit longer to stuff things in there and only stop processing once we reach a high-water mark.

  - a management interface (UDP server, gRPC server whatever), should be able to hook into that select as well to get called (via the closure mechanism) whenever there is something new. Given that we don't need any threads, it is free to gather all the information it needs without locks before replying to its request.

That way, we don't need threads and keep the code simple (also, there is only one core, so we wouldn't get anything from threads).

Cheers,

  -h