Project

General

Profile

Actions

Feature #554

open

Detect infinite recursion when evaluating requirements

Added by Alina Lenk 5 months ago. Updated about 2 months 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 1 (1 open0 closed)

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

Actions
Actions #2

Updated by Alina Lenk 5 months ago

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

Updated by Alina Lenk 5 months 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 5 months 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 5 months 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 5 months 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 5 months ago

Actions #8

Updated by Alina Lenk 5 months ago

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

Actions #9

Updated by Marko Lindqvist about 2 months ago

  • Target version changed from 3.2.0-d3f to 3.2.0

Stopping blocking d3f with this. This does not require changes to the format, but is a bug inside specific format. We hope that the bug will get fixed before final 3.2.0 release, but let's not hold d3f by it.

Actions #10

Updated by Marko Lindqvist about 2 months ago

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

Also available in: Atom PDF