Appropriate way to query display-input-stream

[dmb2]

Is there a way to query what the current display's input stream is? We currently depend on it in io-channel-ioport in the following way:

(defmethod io-channel-ioport ((io-loop sbcl-io-loop) (channel xlib:display))
  (io-channel-ioport io-loop (xlib::display-input-stream channel)))

If not, can we get this symbol exported so that we don't have to worry about the API breaking in the future?

[JMC-design]

For what reason do you need access to the stream? How have the available tools failed to provide you what you need. Is your whole system going to fail if it finds something besides a stream, say a mmap'd buffer?

[dmb2]

I’m not the author of the original code, but since it is integrated in our codebase, I am responsible.

I’m not demanding you export a symbol. In fact, I expect you to avoid that at all costs.

I am not an expert. Please help me find a workable solution that doesn’t require internal symbols in clx instead of interrogating me with questions about my intent and why the esoteric APIs available have failed to meet my needs. I looked to find a way to find the current displays input stream, but I can’t.

I expect that ioloop generalizes the io of stumpwm to work with multiple streams and that the original author needed access to the input stream of the open xlib display in order to listen to the various x11 events required of stumpwm. This is all conjecture and I am definitely not an expert in clx or the intricacies of how io streams are handled.

[dkochmanski]

@dmb2 this snippet only shows, that you access the stream (i.e not how it is used). If you just need to see what are the events please look into functions related to event handling, i.e

process-event, set-event-handler etc

if you want stream-like interface you may wrap process-event in a gray stream and use that.

[dmb2]

Ah, sorry I didn’t give more context! We’re trying to eliminate uses of internal methods in stumpwm (https://github.com/stumpwm/stumpwm/issues/502)

Where the stream above comes in is in ioloop.lisp: https://github.com/stumpwm/stumpwm/blob/master/ioloop.lisp

See the header, it contains the logic for how the streams work. I didn’t write the code so I don’t really know what an adequate substitute would be. I’m hoping you can suggest a viable alternative since you know what the stream we’re currently using represents. I don’t think we’re using it as a random stream because it was convenient.

[dkochmanski]

I don't follow fully logic in this file (but hey, I'm not the stumpwm developer), but given how it is implemented I see you are depending heavily on sbcl's select, so you "want" a file descriptor (not even a stream!) and that can't be provided by xlib via its API. What's more, it is unlikely that it will be exported, because using symbol directly violates the abstraction separation.

If you want to get rid of accessing internal symbols you should model your loop to use "listen" on streams and process-event with peek-p flag T to see which have data. Then you (sleep +sleep-time+) and update remaining time -- loop over. This ugly solution will have also a benefit -- it will work portably on other implementations.

So either you need to keep the internal symbol access (and risk breakage in future) or rewrite the io-loop to not depend on stream file descriptors.

[dkochmanski]

alternatively you may model it by having a thread for each channel which fills a fifo queue.