[vlendec at samba.org: [SCM] Samba Shared Repository - branch master updated]

tridge at samba.org tridge at samba.org
Mon Feb 28 17:12:31 MST 2011


Hi Volker,

 > What shall we do about those? From my point of view the
 > tevent select backend should be removed. With the libreplace
 > poll implementation we get the same functionality.

I have sometimes found having the select() backend for tevent quite
useful, for two reasons:

 1) strace displays select calls much better than it displays epoll
    and poll. This is extremely useful when debugging a tricky
    problem. I've sometimes forced the select backend just so I can
    debug a problem more easily with strace

 2) there are some subtle interactions between fork() and epoll(), and
    when I suspect that one of those subtle interactions may be biting
    us, I tend to switch to the select() backend to see if the problem
    still happens. The poll() interface doesn't suffer from the subtle
    fork() interactions that epoll() does, so perhaps switching to the
    poll() backend would serve the same purpose

I don't see the disadvantage of keeping the select backend as an
option. I know it has the FD_SETSIZE limitation, but since the checks
were added on that it isn't such a problem.

I also like having a range of backends as it means we are less likely
to specialise the code so it only works with one backend. We may well
need to accomodate more backends in the future in order to work well
with other frameworks (eg. the python twisted framework). The select
backend is also very simple and provides a good base example.

 > The standard backend has the fallback to select, which seems like
 > some code duplication from the select and epoll backends.

yes, the runtime fallback was added because epoll() was a a fairly new
call at the time, and was still not well tested.

 > A relatively easy but inefficient way would be to set up the poll
 > arrays in every tevent loop.

That would be pretty slow for Samba4 in single process mode with a
large number of connections. I think it is worth the effort to
maintain these properly on add/del.

Cheers, Tridge


More information about the samba-technical mailing list