> So if TCL_DONT_WAIT isn't set, it will block; if it is, it will
> busy-wait. Looks like we lose either way.
>
> In-between, it invokes the setupProcs of each input source, so that
> they can set a maxblocktime, but I don't think _tkinter should hack
> itself into that process.
That's correct - I should have looked a bit more into what I did
before (I was always tying in another GUI's event loop). However,
I don't see why you should not consider the extra event source.
Tk uses this itself for X. It would be something like:
[in tk setup]
Tcl_CreateEventSource(TkinterSetupProc, NULL, NULL);
/*
*----------------------------------------------------------------------
*
* TkinterSetupProc --
*
* This procedure implements the setup part of the Tkinter
* event source. It is invoked by Tcl_DoOneEvent before entering
* the notifier to check for events on all displays.
*
* Results:
* None.
*
* Side effects:
* The maximum block time will be set to 20000 usecs to ensure that
* the notifier returns control to Tcl.
*
*----------------------------------------------------------------------
*/
static void
TkinterSetupProc(clientData, flags)
ClientData clientData; /* Not used. */
int flags;
{
static Tcl_Time blockTime = { 0, 20000 };
Tcl_SetMaxBlockTime(&blockTime);
}
In fact, you can look at tk/unix/tkUnixEvent.c to see something
similar already done in Tk.
> About thread-safety: Is Tcl 8.3 thread-safe in its standard
> installation, so that we can just use it from multiple threads? If
> not, what is the compile-time check to determine whether it is
> thread-safe? If there is none, I really don't see a solution, and the
You would compile with --enable-threads (both Tcl and Tk).
Jeff
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4