Overview
Artifact ID: | cb779fc03defc0b86c7ae83076d830299c1158d2f4a1e777ad7237670d2218ee |
---|---|
Ticket: | ef28eb1f15167156c8984df7ef430574743255bd
TCL_FILE_EVENTS cannot drive async I/O alone |
User & Date: | dgp 2021-06-16 17:48:33 |
Changes
- icomment:
That change doesn't really address the issue here, best I can recall. After the change, it remains true that I/O operations cannot fully function with support of TCL_FILE_EVENTS only, and TCL_TIMER_EVENTS have to be working too. The shift is just in whether a reflected channel can make a choice of synchronous [chan postevent] or use [after] to create async operations. After the change, [chan postevent] itself is asyncronous by use of timer events internally created. The need for timer events is still there, just out of script-level control. The other effect is to remove the ability for a synchronous use of [chan postevent], which is at least the incompatible change of loss of function in a public command.
- login: "dgp"
- mimetype: "text/plain"