By doing this you open a whole new can of worms. How long is too long? Sometime on a non-realtime system, you may get a big latency spike, maybe some housekeeping is going on, whatever, sometimes, things go slow. Finding the right balance is hard, too long a delay and it doesn't protect enough, as if such queries are repeated, it can still stall your system. Too short and you may kill legitimate queries.

Much simpler in these cases to use a regex engine with runtime guarantees. It may not support some advanced features, but you are sure that it won't explode.

Whether you chose to use a regex engine with runtime guarantees or one that support NP-hard features depends on the situation. If you are in control, it is not worth limiting yourself for the rare case it might explode, just Ctrl-C if it happens and move on. But on an automated system that deals with user data, you want the guarantees.

> use a regex engine with runtime guarantees

That's a good idea.

If you have to use one that supports NP-hard features I think a configurable CPU time timeout is also a reasonable backstop, just as configurable timeouts are reasonable in network code.