14

        XXX: you must keep a reference to the event_base around yourself!

    15

        XXX: what happens to events once we are destructed?

    16

    17

        Libevent has its own asynchronous signal-handling mechanism that is incompatible with Python's signal-handling

    18

        mechanism.

    19

    20

        Technical details:

    21

            Python's signal handlers will simply set a flag corresponding to the signal, and wait for

    22

            PyErr_CheckSignals to be run. Following this, libevent's epoll/select/etc() call will return EINTER - but

    23

            this will only cause libevent to check its own signal state, and continue running.

    24

    25

        To solve this, we register a "wakeup fd" in Python's signal handling system, whereby a byte is written to a

    26

        socket pair whenever python's signal handler runs. We then register an (internal) event for the other end of

    27

        this socketpair in the event_base, which then runs the python signal handlers from "inside" of .loop(),

    28

        propagating exceptions out of .loop() - this solution is more or less equivalent to how libevent's signal

    29

        handling works.

    30

    31

        This means that python's default signals and any other signals added using the signal module continue to work

    32

        at the cost of some additional complexity, but any libevent signal-events also work as well :)

    33

    34

        XXX: currently, you can only have one event_base at a time - there should be separate types used for the main

    35

        thread and sub-threads, since the python signal handling mechanism only works in the main thread.

    36

    37

        XXX: the propagate-exceptions doesn't actually work either, it just aborts the event loop :)

    38

    41

    47

    # internal event for PySignal wakeups

    48

    cdef lib.event *ev_pysignal

    49