|
|
|
|
|
|
by gpderetta
91 days ago
|
|
|
> This doesn't really have anything to do with async signal safety. TLS not being async signal safe is explicitly called out on the article as the reason the token is sent in clear text. > Handle it as a synchronous event in a main loop Of course of you rearchitect the client there are better solutions. But again, the article mentions that's not planned for now. By comparison, delegating cancellation to a background background thread can be done non-intrusively. In principe no code outside the cancel path need changing. Edit: the article mentions that there is a refactor in the works to implement cancel over tls [1]. Turns out that they decided to use a thread (with a pipe for signaling). [1] https://www.postgresql.org/message-id/flat/DEY0N7FS8NCU.1F7Q... |
|
|
pthread_create() isn't async signal safe, though, so they can't simply move their socket code for the cancellation into another function and call pthread_create() on it. They still have to get the main thread to stop doing what its doing (usually via the pipe trick) in order to create the thread, which could easily be a big refactor.
> Edit: the article mentions that there is a refactor in the works to implement cancel over tls [1]. Turns out that they decided to use a thread (with a pipe for signaling).
Seems odd to me to bother. If you have to do the pipe thing, why not just do the new connection for cancellation in the main thread once it sees the data on the pipe? I guess that way they can return control of the CLI to the user while they cancel in the background, rather than blocking the user while the cancellation is going on. But as a user, I kinda would like to know that the query I just cancelled actually got cancelled, a property that the old code has, but the new code won't.
(Presumably the new code can print a warning if cancellation fails, but it could take a long time to fail, and in the meantime the user has moved on.)