[mosh-devel] Libevent

[Timo J. Rinne]

Hi

I of course meant:

Select::add_write_fd() and Select::write().

On 20130514 17:27, Timo J. Rinne wrote:
> 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
>