Cannot Start or Stop Units anymore, when nothing reads from the job completion channel

[j-licht]

go-systemd/dbus/methods.go

Line 48 in d843340

out <- result

The jobHandler used e.g. by Conn.StartUnitContext blocks for ever if nothing reads from the provided channel.
I think this write to the result channel should be non-blocking, like this:

	c.jobListener.Lock()
	out, ok := c.jobListener.jobs[job]
	if ok {
		select {
		case out <- result:
		default:
			fmt.Println("failed to write result to job channel")
		}
		delete(c.jobListener.jobs, job)
	}
	c.jobListener.Unlock()

I'm not sure, what is the best way to log something or if it's even necessary,

[NotSoFancyName]

I was expecting the same behaviour as @j-licht described, it was surprising that D-Bus connection object was not able to handle any other calls if the caller does not read from the channel. The only downside I am seeing with using non-blocking write is that the other library users might be already reading too late from the out channel and will get an empty string and not the value of a result.

WDYT @Luap99 ?

[Luap99]

Yeah I don't think it is right to turn this into non blocking as it will break all callers that don't read the result before this tries to write.
Arguably this is a caller error not to drain the provided channels. Couldn’t the caller simply pass a buffered channel to avoid the write from blocking?

[NotSoFancyName]

Yeah, that could definitely be solved on the caller's side, but in that case, would it make sense to mention that in the function comment? It is still a bit unexpected to get the whole connection non-functional if you do not drain unbuffered channel

[Luap99]

Sure documenting that makes sense