Serious memory problem in 3.08.1 on all VST - even stock!

[tulamide]

All threads created from within Ruby are local - they are sub-threads of the main thread. So each other thread slows down the main thread. For "join(limit) -> thr" specifically you can read this on ruby-doc.org: "The calling thread will suspend execution and run thr"

The code calls "priority". This only makes sense if there are at least two threads. This method is just a hint for Ruby, like a table of importance. If there's one thread set to 0 and another set to 1, than the latter has a higher chance to be called more often than the former. But "priority" does not set a specific calling speed or something. Following the code there's only one thread created. And even if there would be several, they are all then set to the same priority - which again makes it redundant to call at all.

If that line produces all the issues, why not using standard programming instead of a thread? There are quite some ways to implement a timeout (like 'break' from a loop, raising an error, etc.)

[MyCo]

There are quite some ways to implement a timeout (like 'break' from a loop, raising an error, etc.)

I haven't found one single other way yet. But Please show me...

call this function (and you're not allowed to alter it at all!!!)

Code: Select all

def thisIsBroken
    sleep
end

without triggering FS own Ruby timeout (that'll disable Ruby).

[tulamide]

There are quite some ways to implement a timeout (like 'break' from a loop, raising an error, etc.)

I haven't found one single other way yet. But Please show me...

call this function (and you're not allowed to alter it at all!!!)

Code: Select all

def thisIsBroken
    sleep
end

without triggering FS own Ruby timeout (that'll disable Ruby).

I'm not sure if this should be handled at all, since #sleep suspends the thread. If FS detects that as excessive processing, something is wrong with the detection code, isn't it?

One idea I have would be to implement Interrupt or its main class SignalException. But that could only be done from the main loop, not within a RubyEdit class.

It could be something like that:

Code: Select all

begin
   whateverRubyEdit.call(whatever method)
rescue SignalException => e
   ## this will react on any incoming signal, like an interruption command from the keyboard, or a Process.kill('INT', Process.pid)
end

[MyCo]

no, you don't get what this is used for. It basically kill anything that the user put into RubyEdit that takes too long to execute, sleep is a perfect example for this. When you write down sleep in the editor then FS is going to die without this timeout. There won't be any exception, just dead...

[tulamide]

Then it should be prevented to use any of the god methods. Making sleep unavailable (it isn't of any use in FS anyway). I know what you mean, it's just that suspending is the complete opposite of excessive processing. That was my point. I keep an eye on other potential ways to interrupt a method, but for certain there is none that reacts quicker than the strange FS excessive processing routine - it acts immediatly!

[tulamide]

BTW, do you know that the thread can be woken again after sleep with Thread.run ? Just asking.

[MyCo]

yep, but doesn't help much because when there is an exception in the thread, the thread dies and you can't wake the thread up again. You can't catch those exceptions inside the thread because then you won't get any error reporting... everything's a bit shitty.

[FlowStoner]

yep, but doesn't help much because when there is an exception in the thread, the thread dies and you can't wake the thread up again. You can't catch those exceptions inside the thread because then you won't get any error reporting... everything's a bit shitty.

no true....
try this in the ruby edit

Code: Select all

Thread.abort_on_exception = true

t1 = Thread.new do
  watch "In new thread"
  raise "Exception from FS thread"
end

sleep(1)

[FlowStoner]

Hi MyCo,
Have you tried the Ruby Timeout class?
It only needs small adjustments, but the best logic to handle a thread timeout is that, you can not do much more.

[nix]

Hey LaLaLand,
PhenOMEN doesn't leak coz the knobs are not Ruby- is prolly why

I can confirm that the leak is fixed in the Alpha