News for hackers. Stuff that matters.
Re:Berry is a ultra-lightweight dynamically typed embedded s... by foobazgt on Saturday October 07, 2023 @06:25PM (#37806052)
I'd love to better understand what you're describing. Thread-level compute limits generally seem like they need to be managed in some sort of cooperative fashion, otherwise you end up with the possibility of dangling locks and other kinds of corruption on forcible termination.

What signal are you sending to the running thread? What's the handler look like? How does that translate to terminating the thread? How do you do this forcibly (without cooperation from user code)? Schemes that I have seen look more like generating/ instrumenting polling/checkpoints into user code.

Re:Berry is a ultra-lightweight dynamically typed embedded s... by loa_in_ on Sunday October 08, 2023 @05:03AM (#37808949)
You let it operate on a copy of the input data and check integrity afterwards. If it doesn't reach a valid state you discard it as failed/corrupted.
Re:Berry is a ultra-lightweight dynamically typed embedded s... by foobazgt on Sunday October 08, 2023 @04:29PM (#37814137)
There are many pieces of process global runtime state that can get corrupted that are irrelevant to the input data.

You can get lucky and sometimes avoid corruption, but eventually you're going to hit something important like leaving a libc heap allocator mutex locked when you kill a thread in the middle of an allocation.

Re:Berry is a ultra-lightweight dynamically typed embedded s... by lelanthran on Sunday October 08, 2023 @07:19AM (#37809554)
He's describing killing a thread using a watchdog.

This doesn't limit compute power of the thread.

It's an all or nothing approach; either the thread runs or is killed, which doesn't work (as you point out) for all circumstances where you want to limit the amount of compute pwr a thread can use.

Re:Berry is a ultra-lightweight dynamically typed embedded s... by foobazgt on Sunday October 08, 2023 @04:23PM (#37814088)
They're describing sending a signal to a thread, not "killing" it. IIRC, the only thing tgkill is going to do for you is ensure which thread runs the signal handler. For example, if you send a SIGTERM, (IIRC), you will terminate your entire process.