undroidwish

Further ideas regarding my last comment on https://core.tcl.tk/tcl/tktview/f4f44174 Instead of directly calling sigprocmask(2), the tclXsignal.c module needs to call a new (to be defined) Tcl core function which interacts with...

A follow up on my last post. Check-in https://www.androwish.org/index.html/info/41498ca0a57c2aa7 now implements most of the outlined ideas. POSIX signals (per Tclx and Tcl_AsyncMark) are routed through the notifier thread which delivers...

Fred, I see your point regarding assumptions about the runtime environment. And I'd like your TIP to be adopted, soon, not later. However, can we please agree on these points:...

One more thought while glimpsing of the list of signal safe syscalls (http://man7.org/linux/man-pages/man7/signal-safety.7.html): Instead of handling signals in a dedicated thread it should be possible in a special signal safe...

The longer I think over Tcl_AsyncMark reading the first sentence of the manpage ("These procedures provide a safe mechanism for dealing with asynchronous events such as signals...") the more am...

Meanwhile my first approach evolved, see check-in https://www.androwish.org/index.html/info/40790af1e8e4ec9f The basic idea is now to redirect signals to the notifier thread using a new core function Tcl_AsyncMarkFromSignal(), which compared to Tcl_AsyncMark()...

Impressive progress, congratulations. OTOH, I'd still like to read some comment by FA on my last sentence in my last posting: "To extrapolate a flawed interface or to introduce binary...

With the help of dkf TIP#511 aka https://core.tcl.tk/tips/doc/trunk/tip/511.md is now available and hopefully clarifies my arguments somewhat. For me, it seems impossible to safely catch signals synchronously, however, to channel...

Another remark: now that TIP#511 is out, IMHO discussion should be further go on the core.tcl.tk mailing list.

Further simplified the changes for Tcl 8.6 in check-in https://www.androwish.org/index.html/info/eec9d69bc196db31