On 9/19/05, Ivan Boldyrev lispnik@gmail.com wrote:
On 9236 day of my life fahree@gmail.com wrote:
Maybe you didn't realize that we were talking about Lisp and not C. Asynchronous interrupts at the Lisp level need not be asynchronous signals at the C level. Lisp interrupts can be either higher-level than the C level (already handling your sig_atomic_t and then doing something when back from the signal handler),
Then proper handling of sig_atomic_t is problem of Lisp system, not Lisp programmer.
That's only the case if you're using C signals and wants to write in shared memory in C-multithreaded environment. A Lisp implementation may offer user-visible threads that have asynchronous interrupts at the lisp level and NOT USE ANY OF THE ABOVE AT ALL. And actually, that's what Erlang does and Erlisp could typically do: spawn one unix process per processor, each being the host of zillions of Erlang processes, that do not rely the least on either unix signals or unix shared memory for their internal asynchronous interrupts and communication.
It's not limitation of C library, it is limitation of architecture.
The C library definitely does add limitations in terms of reentrancy, memory model, lack of PCLSRing, etc. There are few system calls you can do from a C signal handler, yet the kernel would happily oblige you on all of them.
Layer of C library over signal API is too thin to limit something.
Bullshit. errno alone is enough to bring quite a lot of problems.
No matter if you write you program in C, asm or Lisp, if processor can't write something atomically, you can't use it in async. interrupts.
You can't imagine that the async interrupts in Lisp don't have to be async interrupts in C. And you don't need your processor to write anything atomically if you're not actually using multiple concurrent processors, which won't happen if you have only one process and thread at the C level.
For example, no matter which language you use, you can't atomically write or read 64-bit integer (aka long long) with x86 platform.
64-bit, you can actually (but then you'll tell me about some bigger size). However, it doesn't really matter what you can or cannot write atomically to shared memory, since the whole point of Erlisp is to avoid the shared memory model of concurrency.
I grant you this: if we want to catch unix signals and send asynchronous interrupts of Erlisp processes from them, then whenever we call foreign C code that may be non-reentrant, we must wrap that code into a proper flag polling mechanism (which needn't be atomic since it's per-thread) that allows us to achieve PCLSRing by calling the rest of the signal handler when the thread is safely out of the potentially problematic C code. All this needn't apply when we're running "normal" code generated by a compiler we control, at which time you may use more hacking techniques for PCLSRing.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Amateurs talk strategy. Professionals talk logistics. - old military saying