Tcl_AsyncCreate(3tcl)

💅 Tcl_AsyncCreate — handle asynchronous events ✨

okay bestie, you've stumbled into the Tcl_AsyncCreate(3tcl) page from the Tcl Library Procedures, and honestly? this one is lowkey the backbone of "don't touch anything while the script is mid-sentence." let's get into it 🫶

---

✨ NAME ✨

Tcl_AsyncCreate, Tcl_AsyncMark, Tcl_AsyncMarkFromSignal, Tcl_AsyncInvoke, Tcl_AsyncDelete, Tcl_AsyncReady — the whole girl gang that handles asynchronous events 🌈

---

🎀 SYNOPSIS 🎀

#include <tcl.h>

Tcl_AsyncHandler
Tcl_AsyncCreate(proc, clientData)

void
Tcl_AsyncMark(async)

int
Tcl_AsyncMarkFromSignal(async, sigNumber)

int
Tcl_AsyncInvoke(interp, code)

void
Tcl_AsyncDelete(async)

int
Tcl_AsyncReady()

---

🌸 ARGUMENTS 🌸

• Tcl_AsyncProc *proc (in) — the procedure you invoke to handle an asynchronous event, she's the main character of this whole situation 👑
• void *clientData (in) — a one-word value you pass along to proc. little gift, big meaning 🎁
• Tcl_AsyncHandler async (in) — the token for the asynchronous event handler. your backstage pass 💅
• int sigNumber (in) — POSIX signal number, for when you're in a signal context 📡
• Tcl_Interp *interp (in) — the Tcl interpreter where the command was being evaluated when the handler got invoked, or NULL if the handler was invoked while no interpreter was active. ghost mode, basically 👻
• int code (in) — the completion code from the command that just finished in interp, or 0 if interp is NULL 🔢

---

💖 DESCRIPTION 💖

These procedures give you a safe mechanism for dealing with asynchronous events like signals. and bestie, the "safe" is doing a LOT of work in that sentence, so let's talk about why.

If an event like a signal happens while a Tcl script is being evaluated, it is not safe to take any substantive action to process it. not even a little. for example, it's not safe to evaluate a Tcl script, because the interpreter may already be in the middle of evaluating a script — imagine interrupting someone mid-sentence to make them start a whole new sentence 😭 it may not even be safe to allocate memory, because a memory allocation could already have been in progress when the event hit.

so the only safe approach is: set a flag saying "hey, this event happened," then handle the event later, when the world has returned to a clean state — like after the current Tcl command completes. delayed gratification, but make it systems programming ✨

Tcl_AsyncCreate, Tcl_AsyncDelete, and Tcl_AsyncReady are thread sensitive. They access and/or set a thread-specific data structure in the event of a core built with --enable-threads. The token created by Tcl_AsyncCreate contains the needed thread information it was called from, so that calling Tcl_AsyncMarkFromSignal or Tcl_AsyncMark with this token will only yield the origin thread into the asynchronous handler. it remembers where it came from, fr fr 🧵

Tcl_AsyncCreate creates an asynchronous handler and returns a token for it. The asynchronous handler must be created before any occurrences of the asynchronous event it's meant to handle — and no, it is not safe to create a handler at the time of an event. you have to set up the situation before the situation arrives, periodt.

When an asynchronous event occurs, the code that detects the event (like a POSIX signal handler) should call Tcl_AsyncMarkFromSignal with the token for the handler and the POSIX signal number. The return value of this function is true when the handler will be marked, false otherwise. For non-signal contexts, Tcl_AsyncMark serves the same purpose. Tcl_AsyncMarkFromSignal and Tcl_AsyncMark will mark the handler as ready to execute, but they will not invoke the handler immediately — no jumping the queue, bestie 🙈

Tcl will call the proc associated with the handler later, when the world is in a safe state, and proc can then carry out the actions associated with the asynchronous event. Proc should have arguments and result that match the type Tcl_AsyncProc:

typedef int Tcl_AsyncProc(
        void *clientData,
        Tcl_Interp *interp,
        int code);

The clientData will be the same as the clientData argument passed to Tcl_AsyncCreate when the handler was created. If proc is invoked just after a command has completed execution in an interpreter, then interp will identify the interpreter in which the command was evaluated and code will be the completion code returned by that command. The command's result will be present in the interpreter's result. When proc returns, whatever it leaves in the interpreter's result will be returned as the result of the command, and the integer value returned by proc will be used as the new completion code for the command. handing the baton, iconic behavior 🏃♀️

It's also possible for proc to be invoked when no interpreter is active. This can happen, for example, if an asynchronous event occurs while the application is waiting for interactive input or an X event. In this case interp will be NULL and code will be 0, and the return value from proc will be ignored. (she's just out here doing her own thing, no notes 🦋)

The procedure Tcl_AsyncInvoke is called to invoke all of the handlers that are ready. The procedure Tcl_AsyncReady will return non-zero whenever any asynchronous handlers are ready; it can be checked to avoid calls to Tcl_AsyncInvoke when there are no ready handlers. Tcl calls Tcl_AsyncReady after each command is evaluated and calls Tcl_AsyncInvoke if needed. Applications may also call Tcl_AsyncInvoke at interesting times for that application. For example, Tcl's event handler calls Tcl_AsyncReady after each event and calls Tcl_AsyncInvoke if needed. The interp and code arguments to Tcl_AsyncInvoke have the same meaning as for proc: they identify the active interpreter, if any, and the completion code from the command that just completed. vibe check, then act 💅

Tcl_AsyncDelete removes an asynchronous handler so that its proc will never be invoked again. A handler can be deleted even when ready, and it will still not be invoked. gone, and staying gone 💀

If multiple handlers become active at the same time, the handlers are invoked in the order they were created — oldest handler first. The code and the interpreter's result for later handlers reflect the values returned by earlier handlers, so that the most recently created handler has last say about the interpreter's result and completion code. If new handlers become ready while handlers are executing, Tcl_AsyncInvoke will invoke them all; at each point it invokes the highest-priority (oldest) ready handler, repeating this over and over until there are no longer any ready handlers. seniority rules, the OGs go first 👑

---

🔥 WARNING 🔥

It is almost always a bad idea for an asynchronous event handler to modify the interpreter's result or return a code different from its code argument. This sort of behavior can disrupt the execution of scripts in subtle ways and result in bugs that are extremely difficult to track down. like, you will be staring at this for three days, bestie. don't do it 😭

If an asynchronous event handler needs to evaluate Tcl scripts, then it should first save the interpreter's state by calling Tcl_SaveInterpState, passing in the code argument. When the asynchronous handler is finished, it should restore the interpreter's state by calling Tcl_RestoreInterpState, and then returning the code argument. save your work before you mess with things, that's the rule 🎀

---

⭐ KEYWORDS ⭐

asynchronous event, handler, signal, Tcl_SaveInterpState, thread

---

and that's the whole page, bestie! this was the Tcl_AsyncCreate(3tcl) manual page from the Tcl Library Procedures, Tcl 7.0 era, and she ate. no cap 💖✨ go set your flags and handle things later like a responsible icon 🦋