On Fri, Mar 2, 2012 at 11:01 AM, Peter Stuge <[email protected]> wrote: > Mitchell Hashimoto wrote: > > I'd like to stay away from callbacks now. It complicates many details. > > It's not so bad, libssh2 is not thread safe anyway, so there would > not be many problems. > > > > If libssh2 were to return a list of ready channels, would it buffer these > > all somewhere? Does libssh2 already do this internally (which would make > > this easy)? > > It does already. If you're in blocking mode and call _channel_read() > on one channel, but a packet for another channel comes in, libssh2 > has to deal. >
Ah perfect. > > I'm with Daniel about supporting multiple channels. Taking it a > little bit further I think it might not be a bad idea to model the > API after select() and poll(), meaning that the caller provides a > list of currently interesting channels, and libssh2 returns saying > what action there is to take. > > I agree that a `select()` would be nice but of course it can't be modeled like the `select` syscall since I think channel IDs increase monotonically, correct? Because of that, marking a bitmap of the ready channels would quickly grow out of control for SSH sessions that are held open for a long amount of time. Perhaps instead a kqueue-like interface would be appropriate where you constuct an opaque `channel_group` like structure that contains the channels you care about. Channel IDs are simply numbers, so libssh2 can do some sort of efficient search/sort in order to quickly check if channel X (which it has received a packet for) is in the channel group. This could be efficiently implemented, although of course now the complexity is rising. Or, perhaps simpler, the API can be something like the following: int libssh2_session_channel_ready(LIBSSH2_SESSION *, LIBSSH2_CHANNEL **buffer, int size) Where `size` is the maximum size of the `buffer`, and the API would return the number of channels that are ready to be read, and the `buffer` would be an array of ready channels. This would be pretty easy to implement from an API perspective, but puts more of a burden of performance onto the client. Mitchell > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel >
_______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
