SvelteKit의 +page.svelte가 +page.ts를 기다리는 구조가 SSR 시에는 복잡도를 엄청 줄여주는데 (데이터가 다 로딩되어 있어서 <Suspense> 등이 필요 없으니까...) CSR 때는 페이지 렌더링을 늦추는 주범이 되는 것 같아서 고민
Search results
지금 아이디어는 load에서 SSR인지 여부에 따라서 T | Promise<T>를 던져서 SSR에서는 바로 데이터 / CSR 에서는 Promise 결과가 스트리밍되게 하고 +page.svelte에서는 항상 #await :then을 씌워주면 SSR때도 Promise 아닌게 들어오면 :then을 렌더링하니까 어떻게 될 거 같긴 한데 어쨌든 SvelteKit의 간단한 구조는 포기해야 하니까... (어쩔 수 없는거지 싶기도 하고)
Today, I implemented the #async / #await pattern (as known from #csharp and meanwhile quite some other languages) ...
... in good old #C! 😎
Well, at least sort of.
* It requires some standard library support, namely #POSIX user context switching with #getcontext and friends, which was deprecated in POSIX-1.2008. But it's still available on many systems, including #FreeBSD, #NetBSD, #Linux (with #glibc). It's NOT available e.g. on #OpenBSD, or Linux with some alternative libc.
* I can't do anything about the basic language syntax, so some boilerplate comes with using it.
* It has some overhead (room for extra stacks, even extra syscalls as getcontext unfortunately also always saves/restores the signal mask)
But then ... async/await in C! 🥳
Here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___async_task.html
I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad. 🥳
The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.
Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...
The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution. 😎
In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
https://github.com/Zirias/swad/blob/57eefe93cdad0df55ebede4bd877d22e7be1a7f8/src/bin/swad/cred/pamchecker.c