stellentus / go-plc Goto Github PK

It would be nice to be able to distinguish between errors writing to the PLC and errors in the provided tag/value. Then users know whether the error was in their request, or in the network.

In the #29 branch, the Prioritizer will essentially blast the downstream Reader with ready-to-run operations. Pooled job, of course, is to bound concurrency, but a consequence of this is we will have a bunch of goroutines essentially queuing behind Pooled.

One way to solve this is for the Prioritizer to have a bounded concurrency level like async. That'll at least prevent an unbounded number of goroutines queuing behind the Pooled but it's not immediately obvious what the concurrency level in Prioritizer should be set to; additionally, since the go scheduler is not aware of priority levels AFAIK it could wake up any thread blocking on Pooled, leading to priority inversion.

It might be nice for Pooled to expose an EAGAIN or EWOULDBLOCK error as a backpressure mechanism. This means the Prioritizer can attempt a backoff.

By all accounts we have enough headroom given the number of priority-zero tasks that I don't expect that this will become an issue, but I'm putting this down just in case it becomes an issue and we need ideas.