Adapt ByteCode to handle interrupted thread in compute loop LDEV-2573

[xdecock]

This is a quite aggressive approach to allow loops to be cooperatively pre-empted.

Not sure it's ideal, the bytecode can more than probably be optimized, and the "tick" frequency should be adjusted.

This allows to escape from computationaly heavy loops and avoid the stop() call.

without this approach, a simple

<cfscript>
local.a=2
do {
local.a=local.a;
} while(true);
</cfscript>

Would kill the server for hours.

I'm open for suggestion on how to make this more efficient.

[bdw429s]

Better interrupt behavior would be useful from CommandBox CLI as well as Ctrl-C sends an interrupt to the main thread, but many operations inside of Lucee don't check for interrupt so Ctrl-C does not stop the process like it should.

@xdecock have you tested this to see how much overhead it adds? I've noticed overhead when I call Thread.isInterrupted() a lot from CFML code, but I'm not sure if the overhead actually comes from the reflection.

[xdecock]

Hello, there is definitively overhead, that's why, it's only done one time out of 10K iteration, and when leaving a loop.

The + side of thing is it avoids the Tomcat ThreadDeath problem.

I'm still trying to figure out how to handle the unit tests, and i'd like to be able to add a preempt option to the tags, being a number or false

so something like:

<cfloop from="1" to="10000000" preempt="false" index="idx">
</cfloop>

That might disable preemptive code at compile time or

<cfloop from="1" to="10000000" preempt="300000" index="idx">
</cfloop>

I'd strongly prefer to avoid the read variable so to only compileTime value. this will allow to strip the impact entirely (except a longer compile time obviously)

This also won't protect your server from precompiled classes, as basically, the protection is now at compile time.

Currently, the perf hit to me seems easier to pay than threads killed and just leaking at tomcat level.

[michaeloffner]

i like it, we will consider for Lucee 6.0

[xdecock]

To be honest, this is running in production since last week of november, with high load, and allowed our servers to recover from crashes that previously required full restart due to tomcat leaking thread. I wasn't certain a code change this extensive had chances of being stable, but after a few nights it went pretty well. (and allowed to survive bad loops that were just eating away cpu)

[xdecock]

Should i rebase on the 6.0 branch?

[zspitzer]

yep, 6.0 is preferred :)

also can you remove loader/.settings/org.eclipse.jdt.apt.core.prefs

[xdecock]

finaly fixed :)

[zspitzer]

just an update, this is definitely going to be added to 6

[michaeloffner]

@cfmitrah the underlaying ticket is already set to resolved, if that PR still resolves another issue or improves the current fix, please create a new ticket that links the current and create a new PR.

[xdecock]

This solves thread loss in a lot of cases without reluing on thread stop that causes thread loss in tomcat.

Not sure what else is needed

Le lun. 12 févr. 2024, 12:02, michaeloffner @.***> a écrit :

@cfmitrah https://github.com/cfmitrah the underlaying ticket is already set to resolved, if that PR still resolves another issue or improves the current fix, please create a new ticket that links the current and create a new PR.

— Reply to this email directly, view it on GitHub https://github.com/lucee/Lucee/pull/798#issuecomment-1938459840, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAME7NKPKVT7OF4FHN6T43YTHZFXAVCNFSM4JOGORZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTHA2DKOJYGQYA . You are receiving this because you were mentioned.Message ID: @.***>