[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Jitter] Asynchronous notifications and signals

From: Luca Saiu
Subject: [Jitter] Asynchronous notifications and signals
Date: Wed, 18 Dec 2019 00:25:28 +0100
User-agent: Gnus (Gnus v5.13), GNU Emacs 27.0.50, x86_64-pc-linux-gnu

Hello, and sorry for the recent silence.

I have added support for notifications and signals in what I believe is
a clean style, or at last a style which will not get in the way later.

The intent is supporting signals and other notifications, in a
multi-threaded environment and paying attention to reentrancy.  There
are no synchronization primitives supplied by Jitter, at least for the
time being, but it should be clear which operations have effect on the
global state.  I will have to document it as well, and at least I am
adding stubs for the new features.

This is a fun demo for the Uninspired VM:

--8<---------------cut here---------------start------------->8---
        mov 0, %r0
        add %r0, 1, %r0
        safe-point $out
        b $L
        printfixnum %r0
        mov 0, %r0
        b $L
--8<---------------cut here---------------end--------------->8---

The program handles SIGINT in a clean way, printing the current value of
the counter in %r0 and then resetting it.  The program can be terminated

Now each thread could even handle the signal differently.  The signal
handler function sets some thread-local flags accessible to VM states,
where VM threads poll for changes to it.  The polling VM instruction
(safe-point) is now as fast as it can be:

# 0x2273828: safe-point/fR 0x2273838 (10 bytes):
    0x00007fe46867eba7 48 83 3b 00              cmpq   $0x0,(%rbx)
    0x00007fe46867ebab 0f 85 05 00 00 00        jne    0x00007fe46867ebb6

The thread-local (or VM state-local) notification flag is a field in The
Array, accessible from VM code with a single load instruction -- in the
case of x86_64, executed as part of a comparison with a memory operand.

On other architectures it also does the right thing, as long as fast
branches are implemented efficiently.  This is MIPS, which requires no
separate instruction to compare but has a branch delay slot:

# 0x46478c: safe-point/fR 0x464794 (12 bytes):
    0x7f6febbc 8e020000         lw      $2,0($16)
    0x7f6febc0 14400003         bnez    $2,0x7f6febd0
    0x7f6febc4 00000000         sll     $0,$0,0x0

And this is PowerPC, which does not need branch delay slots but for
which I have not implemented conditional fast branches yet.  With good
fast branches it will be three instructions.  The same for SPARC, ARM
and most other architectures.

# 0x100639fc: safe-point/fR 0x10063a04 (16 bytes):
    0xff77ebbc 80 ce 00 00      lwz     r6,0(r14)
    0xff77ebc0 2f 86 00 00      cmpwi   cr7,r6,0
    0xff77ebc4 41 be 00 08      beq     cr7,0xff77ebcc
    0xff77ebc8 48 00 00 08      b       0xff77ebd0

On RISC-V it will be two instructions.

It would not be inconceivable to add an alternative "reverse safe-point"
instruction, branching if the notification has *not* arrived.  It would
be useful to replace safe-point followed by an unconditional branch,
like in the code above.
However I am forcing myself not to waste too much time in these
optimizations now.

Even if not all of the signal handling code fits quite naturally within VM
instructions (I am thinking in particular about install-signal-handler)
this solution makes the example very easy to play with, and shows every
important piece of the notification API used in a single file.
The four VM instructions in "Safe-point, notification and signal
instructions" are all instructive in this sense.

Tag v0.9.208 .

In the coming days I have decided I will focus on defective instruction
replacement.  Other minor points in my TODO list including libtextstyle
support will be fun, but they are now distracting me from more important

Luca Saiu
* My personal web site:  http://ageinghacker.net
* GNU epsilon:           http://www.gnu.org/software/epsilon
* Jitter:                http://ageinghacker.net/projects/jitter

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]