"Jeffrey Hobbs" <jeffh@ActiveState.com> writes:
> IIRC, Tcl_SetMaxBlockTime is a one-short call - it sets the next
> block time, not all block times. I'm sure there was a reason for
> this, but that was implemented before I was a core guy. Anyway,
> I think you just need to try:
>
> - result = Tcl_DoOneEvent(TCL_DONT_WAIT);
> + Tcl_SetMaxBlockTime(&blocktime);
> + result = Tcl_DoOneEvent(0);
>
> and see if that satisfies the need for responsiveness as well as
> not blocking.
Thanks, but that won't help. Tcl still performs a blocking select.
Studying the Tcl source, it seems that the SetMaxBlockTime feature is
broken in Tcl 8.3. DoOneEvent has
/*
* If TCL_DONT_WAIT is set, be sure to poll rather than
* blocking, otherwise reset the block time to infinity.
*/
if (flags & TCL_DONT_WAIT) {
tsdPtr->blockTime.sec = 0;
tsdPtr->blockTime.usec = 0;
tsdPtr->blockTimeSet = 1;
} else {
tsdPtr->blockTimeSet = 0;
}
So if TCL_DONT_WAIT is set, the blocktime is 0, otherwise, it is
considered not set. It then goes on doing
if ((flags & TCL_DONT_WAIT) || tsdPtr->blockTimeSet) {
timePtr = &tsdPtr->blockTime;
} else {
timePtr = NULL;
}
result = Tcl_WaitForEvent(timePtr);
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.
So I don't see a solution on the path of changing how Tcl invokes
select.
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
Sleep must stay.
Regards,
Martin
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