Andy Melnikov (nponeccop) wrote,
Andy Melnikov
nponeccop

Вопрос об использовании Tk закрыт

https://metacpan.org/pod/AnyEvent::Impl::Tk

Tk is buggy. Tk is extremely buggy. Tk is so unbelievably buggy that for each bug reported and fixed, you get one new bug followed by reintroduction of the old bug in a later revision. It is also basically unmaintained: the maintainers are not even interested in improving the situation - reporting bugs is considered rude, and fixing bugs is considered changing holy code, so it's apparently better to leave it broken.

I regularly run out of words to describe how bad it really is.

To work around some of the many, many bugs in Tk that don't get fixed, this adaptor dup()'s all filehandles that get passed into its I/O watchers, so if you register a read and a write watcher for one fh, AnyEvent will create two additional file descriptors (and handles).

This creates a high overhead and is slow, but seems to work around most known bugs in Tk::fileevent on 32 bit architectures (Tk seems to be terminally broken on 64 bit, do not expect more than 10 or so watchers to work on 64 bit machines).

Do not expect these workarounds to avoid segfaults and crashes inside Tk.

Note also that Tk event ids wrap around after 2**32 or so events, which on my machine can happen within less than 12 hours, after which Tk will stomp on random other events and kill them. So don't run Tk programs for more than an hour or so.
Tags: все пидарасы а я
Subscribe

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 5 comments