[erlisp-devel] Re: async signals

[Faré]

On 9/19/05, Ivan Boldyrev <lispnik at gmail.com> wrote:
> On 9236 day of my life fahree at 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