Tevent hacking

Volker Lendecke Volker.Lendecke at SerNet.DE
Sun Jul 26 02:53:38 MDT 2009

On Sat, Jul 25, 2009 at 11:22:56PM +0000, Timur I. Bakeyev wrote:
> > Signals are notoriously hard to get right. The tevent_signal
> > thing abstracts away most of that ugliness. And, if you for
> > example look at libev, that does not support the sigaction
> > style signals we need for kernel oplock support.
> Well, it'll be nice to get more details what is expected
> from such handling and how alternative mechanisms of
> signals delivery can be used.

Look at linux_oplock_signal_handler(). We need to see the
si_fd field to find out which fd the oplock break is for.

> > And timers -- that's just an obvious thing to do IMO.
> Mmm.. Not for me :) Timers could mean a lot of things and
> I'm not so familiar with the tevent code to say what sort
> of timers it expects. Are these just internal
> implementation, that delivers event after certain
> interval? Or wrappers around timer_create() interface? Or
> setitimer()?  I'm really puzzled.

tevent_add_timer does nothing with the OS, it just calls a
function at a point in the future.

> Well, apparently thats quite new:
>  signalfd() is available on Linux since kernel 2.6.22.
>  Working support is provided in glibc since version 2.8.
>  The signalfd4() system call is available on Linux since
>  kernel 2.6.27.
> The similar restriction applies to timerfd_create()
> interface.
>  These system calls are available on Linux since kernel
>  2.6.25.  Library support is provided by glibc since
>  version 2.8.
> But again, my question - are these timers comparable with
> timers used by tevent?

We use the timeout parameter of epoll or select. That's it.
Everything else is user space.
> And, of course, I'd like to see, how it's all fit into the
> kqueue() mechanism, which provides similar
> capabilities(and inspired epoll() developers, I guess).
> Oh, and, the most crucial one - how to test my new
> implementation :)?

Oh, if it survives "make test" with smbtorture4 on both s3
and s4, I would be quite certain that is not fully broken. :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090726/8aba7b55/attachment.pgp>

More information about the samba-technical mailing list