* Marc-André Lureau (marcandre.lur...@gmail.com) wrote: > Hi > > On Wed, Oct 12, 2016 at 11:15 PM Dr. David Alan Gilbert <dgilb...@redhat.com> > wrote: > > > Hi, > > I had a look at a couple of readline like libraries; > > editline and linenoise. A difficulty with using them is that > > they both want fd's or FILE*'s; editline takes either but > > from a brief look I think it's expecting to extract the fd. > > That makes them tricky to integrate into qemu, where > > the chardev's hide a whole bunch of non-fd things; in particular > > tls, mux, ringbuffers etc. > > > > We could restrict readline usage to chardev with fd? But even with that, > how would it be compatible with mux? It would have to somehow steal/restore > the chardev fd. Alternatively, we could have a "fd pipe"/socketpair chardev > frontend compatible with any chardev. Sounds contrived though, but it > should work, and probably not so much code. (qemu_chr_new_fd_fe?)
Right; you'd still have to be careful about where the code ran that stuffed it down that fd; for example I was thinking that maybe I could connect editline to a pipe, and then just add a handler that streamed that out to the chardev; but I worry that if, in the main thread, I was to pass input to editline that caused it to output a huge amount (say a big tab complete or a max-len filename) then it could deadlock because the thing emptying the pipe wouldn't get run until the main loop returned. editline does have an 'el_push' so you could avoid having a real fd for it's input (or at least an fd that ever does anything) and just call el_push to stuff characters into it's input queue. > > > > If we could get away with just a FILE* then we could use fopencookie, > > but that's GNU only. > > > > Is there any sane way of shepherding all chardev's into having an > > fd? > > > > Ah that would be nice! But I think the point is to stay in userspace (and > avoid extra copy, context switch, or extra fds). Otherwise, it feels like > the whole chr interface could be a socketpair + a thin layer for events, > that would simplify things indeed. Well that would be nice :-) I don't have much sympathy for saving on copies and context switches at the bandwidth the monitor is going at. > > Once you had those then you could also use them in a separate thread. > > > > > You can already use chardev in seperate thread, but I don't know to which > extent (see add_handlers_full for completely seperate thread, locking for > write for multi-writer, I suppose s->chr_read is called from the > dispatching context and is responsability for frontend callback to lock > properly) Oh that's fancy and new. It would be fun to run a monitor in a different thread with that; or use it to drain an output fd. But would you trust multiple threads to drive the two different parts of a mux? Dave > -- > Marc-André Lureau -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
