Project

General

Profile

Actions

Feature #554

open

Detect infinite recursion when evaluating requirements

Added by Alina Lenk 15 days ago. Updated 7 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
General
Target version:
Start date:
05/04/2024
Due date:
% Done:

0%

Estimated time:

Description

Detect recursion with the same requirement in tri_req_present(), log it as a warning and return TRI_MAYBE. This addresses a number of requirement recursion issues, see OSDN #45974.

Targeting this to S3_2 d3f since the status of self-provided goods (OSDN #43724) relies on addressing those issues.


Files


Related issues 2 (2 open0 closed)

Blocks Tasks #397: S3_2 datafileformat freeze (d3f)NewMarko Lindqvist04/02/2024

Actions
Blocked by Feature #600: thread-local storageNew05/12/2024

Actions
Actions #2

Updated by Alina Lenk 15 days ago

  • Blocks Tasks #397: S3_2 datafileformat freeze (d3f) added
Actions #3

Updated by Alina Lenk 15 days ago

Still a couple of questions that might be worth thinking about:

This breaks if requirements are ever evaluated in a multithreaded context. I feel like this could be a problem with threaded AI? Haven't tested that.

There's an argument to be made that this should be an error rather than a warning. The reason I went with warning is to provide leeway for reasonable behavior that only becomes self-referential when evaluating RPT_POSSIBLE with partial information (example).

Actions #4

Updated by Marko Lindqvist 15 days ago

Yes, Tex AI can evaluate tiles for autoworkers actions while the main thread does whatever requirement evaluations. Might also do movement (action enabler requirements) related evaluations in the thread.

Actions #5

Updated by Alina Lenk 15 days ago

  • Status changed from In Review to New

Right. Since there isn't any forking happening during req evaluation, just making it thread-local should work; but it doesn't look like we have (implementation-agnostic) thread-local storage? So we'll either need that, or use a more heavyweight mutex-based solution that would probably cost us quite a bit of the efficiency we're using threads for in the first place.

Actions #6

Updated by Marko Lindqvist 13 days ago

Adding thread-local storage functionality to fcthreads should not be too hard, if we avoid over-engineering it (something just for our specific use-case)

Actions #7

Updated by Alina Lenk 8 days ago

Actions #8

Updated by Alina Lenk 7 days ago

New patch for main branch rebased onto #613. This is still preliminary and not thread-safe.

Actions

Also available in: Atom PDF