[mosh-devel] Libevent

[Timo J. Rinne]

Hi

I think it would surely make cross platform compatibility better.  I
fully agree that it would be a long road to go from where the software
is now.  The implementation is quite straightforward now for the
situation where there usually is static set of file descriptors
(terminal/network protocol etc). When implementing the agent forwarding
(which by the way works great!) I would have optimally needed also
write-set polling, which is not currently done.  For agent forwarding it
was easily circumvented by basically writing output to agent sockets in
synchronous method (but with timeout).

I'm not advocating moving to libevent and probably it would not be worth
the effort.  Just taking down my observations.  I would however suggest
adding add_write_fd() and in_write_set() to accompany add_fd() and
in_read_set().

//Rinne


On 20130514 17:13, Keith Winstein wrote:
> I guess the question is, what would be the benefit and would it be
> painful to keep our current level of cross-platform compatibility?
> 
> It has been a pretty long journey to where we are now. We started out
> using poll() and signalfd() to be able to wait for either IO or a
> signal (like WINCH or INT). But signalfd() isn't available on OS X,
> and on older versions of OS X don't let you poll() on a pseudo
> terminal. So then we switched to a pretty complicated setup involving
> skalibs, which uses either pselect() or the self-pipe trick. But that
> became painful for other reasons (e.g. Debian/Ubuntu's skalibs doesn't
> let you link with PIC; I didn't like distributing a big directory of
> third-party code).
> 
> So now we have a nice abstraction done by Keegan that ends up calling
> pselect(), which works almost everywhere. (And recently supplemented
> by Jeremie to use select() on older versions of OpenBSD.)
> 
> The current approach seems to be fine so I'm not eager to revisit this
> area of the code unless there would be a real benefit. And in
> practice, it seems much more annoying than I had expected to rely on
> these kinds of libraries, because inevitably they aren't available
> somewhere we care about (e.g. Homebrew or MacPorts), which means we
> need to ship a backup copy in our own tree and then keep it updated,
> etc. etc.
> 
> Anyway, those are my thoughts.
> 
> -Keith
> 
> On Tue, May 14, 2013 at 8:42 AM, Timo J. Rinne <tri at iki.fi> wrote:
>> Hi All
>>
>> While browsing through some pull requests and other stuff, I started
>> wondering why Mosh event loop is in the first place implemented from
>> scratch.  I think it is a model case of a program that would be best
>> implemented on top of a library that hides select/poll/epoll/whatnot
>> logic once and for all.
>>
>> It might be a painful project to turn it that way at this point, but I'm
>> sure that eventually it would be worth the effort.
>>
>> Keith?
>>
>> //Rinne
>> _______________________________________________
>> mosh-devel mailing list
>> mosh-devel at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/mosh-devel