Update: Implement "execute" support and fix bugs.

Provide new feature for executing into another program.
This is provided via the new Item Action "execute".

The function controller_perform_ready() is being called and the status is being checked but the status is not being assigned.

There are a few cases where thread.enabled needs to be checked and a few cases it does not need to be checked.

Several of the threads need to be aware of the normal/other status to properly determine the thread.eneabled situation.
Without this, they make incorrect decisions that result in bugs.
I did not want to implement a new structure to resolve this so instead provide custom wrapper functions to call that set the appropriate normal/other state.

The functon controller_thread_process_cancel() now needs to be caller aware so that the caller does not get cancelled.

Feature: add support for F_execute and F_execute_not status codes.

Update: Add documentation about the design problems around POSIX cancellation.

Cleanup: remove extra newline printing on exit after failsafe in verbose mode.

Update: Improve entry/exit verbose messages, display exit with -tv, and wait all with read lock fix.

The verbose messages should be distinguishing between an entry and an exit now.

When both --simulate and --test are specified, the printout should include both the entry and the exit.
Previously, only the entry was printed.

The wait all should only be triggered to wait for all processes at the current moment in time.
Furthermore, the read lock is being held too long (for the entire loop).
Maintain the read lock long enough to build a list of all processes to wait for.

Update: signal wait after each time the state becomes "idle".

This should give processes waiting more opportunities to wake up.

Cleanup: display "exit" instead of "entry" when finished process an exit file.

Progress: redesign processing logic to accommodate different process Rule Actions and update dependency design accordingly.

When I implemented the "exit" support (opposite of an "entry") I noticed a oversight in the design whereas there was no way to distinguish between a process that successfully started via the "entry" or the "exit".
Change the design to now utilize unique Rule Processes for each Rule Action requested.

This required further changes to the status handling.
A rule status is now an array of all possible Rule Actions.
This is utilized using a static array for simplicity purposes (there is no need for a dynamic array here).

All of the recent changes introduced a lot more complex code.
There are now helper functions to help facility common tasks.
This should also make updating easier as there is only one place to update.
The downside is the introduction of an additional function call (which is a tiny runtime cost).

To facility this new design, the Rule files must also be aware of the different Rule Actions.
The "need", "want", and "wish" have been relocated into a new Rule Action called "on".
Additional parameters for an "on" allow for describing the Rule Action in which the dependency applies to.
This allows, for example, a "stop" Action to operate in a different order than a "start" Action.
An example of this is provided.
Look at the data/settings/example/rules/serial/*.rule files.

An example syntax is:
  on start need serial s_1
  on stop need serial s_3

When validate is passed, do not wait for asynchronous processes because they are not run.
Normally this is not noticeable but is exposed when 'script/fail' failed to execute and return ('script/fail' should execute, fail, and return).
This bug is caused by the wait functions not checking to see if the caller is the same as the current process (it was waiting for itself).
This may have been introduced as a result of the redesign.

Progress: Redesign enty/exit rule handling, now requiring Action instead of "rule".

The Entry and Exit files are using "rule" to designate a Rule to operate.
This is designed on the assumption that an Entry always runs a "start" and Exit always runs a "stop".

This behavior is changed such that "rule" is no longer specified and one of the 9 supported Actions may be used.
Such as "start" or "stop", for example.

There is still more work to do as this change doesn't fix the Exit in terms of dependency handling.
Currently, the process structure does not distinguish the Rule action, such as "start" or "stop".
Additional changes to the process structure are needed.

Progress: controller program, add exit support.

This implements the initial work needed to get exit files working.

A new thread is added to handle both "entry" and "exit" to free up the "rule" thread and allow for the "exit" to start will the "rule" thread exists.

The thread enabled process is now more complex given that there needs to be stages so that "exit" threads can work while "entry" or "control" operations begin terminating.
Add several helper functions to help simplify the detection.

Add an "alert" lock to send/receive alerts.
This is a more general purpose lock that tells something waiting on the alert to wake up and see if anything you care about changed.

The file loading now needs to be aware of "optional" files, namely the exit files.
If the named exit file does not exist, then do not care as it is not required (unlike entry and rule files).

Many of the read and write locks are now timed so that they can check to see if the controller is enabled or not.

While working on this I noticed some oversights and things that I did not previously consider.
I need to follow this up with a redesign in the entry/exit rule handling.

Instead of "rule", I should have the rule actions like "start" and "stop".

There needs to be support for default behaviors, such as allow for "stop" to not have a parameter and to correctly find and terminate a service.

There needs to be consideration on dependencies when exiting, perhaps there needs to be an exit-specific dependency management.

Progress: exit prep work, reserve and implement "setting" in entries and exits, add option to "ready', and update documentation.

Add documentation, specifications, and basic structural changes for the "exit" files.

The "entry" and "exit" files now reserve "setting" for designating settings.
Currently, only "entry" supports a setting and that setting is "mode".

The "mode" setting designates how the entry program is intended to behave.
When operating as a "service", the controller program will wait indefinitely for commands (via the not yet implemented "control" program or "control" socket).
When operating as a "program", the controller program will immediately exit after completion.

The "ready" Entry Action now supports "wait".
When "wait" is provided, the "ready" operation will wait for all current asynchronous processes to complete before operating.

Update documentation and specifications, adding the "exit" files.
Cleanup the existing documentation and specifications, fixing wording.

Update: display when done processing entry when verbosity is set to verbose.

Update: include rule status when wait all function when waiting.

Bugfix: asynchronous processes not executing properly according to dependencies.

The controller_process_wait() function is returning immediately because the status is being changed and is only checking for F_time.

Add status_lock to separate it from status.
Return if status is an error.

Require Rule status to be both not F_known_not and not one of "active" or "busy".

If processes are waiting for a while and a signal is received, decrease the wait timer.

Update: use the action of the process type, preparing for implementing exit files and the control program.

Update: implement with pid execution, simplify related rules.

Implement the with pid execution.
This expects the process to be spawned in the background.

After some review, I decided to remove "use" and "create", replacing those with "pid_file".
The reasons are:
- For "use", the spawned service manages the pid file, so it would be overly complicated to try and manage it in addition to the spawned service.
- For "create", if the process is to go into the background, in order to manage it then there would still need to be a running process (this defeats the purpose).

When the termination signal is received, then inform any background process spawned by the controller program to exit, based on the existence of the pid file.

Update: generalize the pid file creation and deletion.

The PID create and delete functions were written as intended specifically for the main controller program.

PID files are to be used by services and utilities, therefore the PID create and delete functions should also be used there.

Detect if the main PID file is created and then only attempt to delete it on exit (and then do not do so for child processes).

Bugfix: invalid file descptor error on stream close.

This caused both flushing to fail and closing to fail.

Make flushing more flexible and more optional, expanding the close functions to be non-autoflushing and autoflushing.

The fclose() closes the file stream and therefore the descriptor will be invalid.
In this case, the descriptor need only be reset to -1.

If the stream property is not populated and "complete" is designated, then close the file by the file descriptor id.

Update: fix file stream error return, improve file error messages, add new status types and remove status types.

The f_file_stream_close() function is missing some errors.

The file error message printer is missing several error messages.
There is also some cleanup is needed in the file error messages (consistency problems, mostly).

Add F_file_overflow, and F_file_underflow for file specific overflow and underflow.
Add missing F_file_descriptor_not.

Remove F_file_allocation and F_file_deallocation, only the generalized F_memory and F_memory_not are used now.

Update: handle F_failure error in fll print function.

Cleanup: relocate fl_color code to f_color and remove fl_color.

Ever since f_string became a core/required/special project where all level_0 could depend on it, fl_color no longer needed to be at level_1.
Relocate fl_color into f_color, removing the fl_color project entirely.

Update all dependencies.
This exposed some missing dependencies in fll_program that fl_color is secretly handling.
Fix that as well.

Feature: controller program must support "with full_path".

This is necessary to accomodate fickle programs like SSHD where the full path in argument[0] is required.

This implements a general feature called "with" which is provided to add flags on a per Rule Type basis.
These flags will tweak the Rule Type is some manner.

Only one flag is suppoted at this time: "full_path".
The "full_path" provides the necessary functionality to make SSHD happy.

Update: redesign fl_execute_parameter_option_path in fll_execute.

The previous design of fl_execute_parameter_option_path seemed pointless because it could be detected if a slash is in the progam name.
Recent changes have utilized the slash in the path to do just that.

While working with the controller program the SSHD program revealed that some programs are fickle about what is in their argument[0].
SSHD wants the full path and as such it needs to be provided.
This makes sense as the normal behavior of most programs when started with a full path general expect a full path in argument[0].

The fl_execute_parameter_option_path is redesigned to instead provide a full path for program and for argument[0].

Examples:
  - "bash my_script.sh" (without fl_execute_parameter_option_path), results in: program="bash", argument[0]="bash", argument[1]="my_script.sh".
  - "/bin/bash my_script.sh" (without fl_execute_parameter_option_path), results in: program="/bin/bash", argument[0]="bash", argument[1]="my_script.sh".
  - "bash my_script.sh" (with fl_execute_parameter_option_path), results in: program="/bin/bash", argument[0]="/bin/bash", argument[1]="my_script.sh".
  - "/bin/bash my_script.sh" (with fl_execute_parameter_option_path), results in: program="/bin/bash", argument[0]="/bin/bash", argument[1]="my_script.sh".

Bugfix: fll_execute does not execute full path.

When passed a full path to a program (rather than depending on detecting in from just a program name) the program does not execute.

There are several logic flaws and mistakes.
- The last_slash should have "+1" to avoid including the slash itself.
- When environment is cleared, it need to potentially use "program" or "arguments.array[0].string" if a slash already exists in the provided name.
- The final NULL at the end of the program_path string is missing.
- The "program" or "arguments.array[0].string" should be used in general instead of always the "program" only.
- The fixated_is is being used incorrectly in private_fll_execute_path_arguments_fixate (and the documentation is incorrect).

I suspect that these functions are messy due to changes in design that were not fully updated (including the appropriate documentation).

Bugfix: properly configure example.

The reason why controller is attempting to execute "/var/run/sshd.pid" is not because it is incorrectly attempting to process the "use" as a start.
Instead, it is because it is properly attempting to do so because it is being told to.

Oops! This is just a simple misconfiguration and not a bug in the code.
A bug in the configuration.

Progress: controller program, begin working on pid file related executions.

It occurred to me that I could quickly create a process with a PID file using a script.
I then realized that "service" only applies to binaries and not scripts.
Add a new type called "utility" that is identical to "service" in purpose except that it processes scripts.

Begin implementing the PID file related code.
It seems there are a few things to address, such as proper test output display.
For example, I am seeing "Simulating execution of '/var/run/sshd.pid' with the arguments: '' from 'SSH Service'.".
That "/var/run/sshd.pid" should instead be "/usr/sbin/sshd".

Creating or checking existence of the PID files is not yet written.
The behavior of after a process forks is not yet written either.

An error needs to be printed and F_failure (with error bit set) should be returned.

The "success = F_failure" should probably have error bit set.

Add new rules and entries for testing this (to be implemented) functionality.

Update the documentation.
Some of the documentation is outdated and as a result, wrong.

Update: implement read lock handlings support.

There are some cases where I am able to figure out a way to make the logic continue on on failure and handle the case of read lock failure.
There are other cases where I am not yet sure how to handle.
Expect more changes in the future to address ability to continue onward on lock failure.

Some functions now return F_lock (with error bit) to designate that the lock failed.
In these cases, it is for functions that require the caller to have a read lock (such as process->lock) locked before starting.
When such functions return the caller now has a way of knowing that the read lock is no longer held.

Remove now pointless "busy" variable.

Update documentation comments with @todo.

Update: handle write lock failures, begin adding support for handling read lock failures.

Get the response on write lock failure.
Present an error message.
Return the error status.

Increase the cancellation timeouts from 0.06 seconds to 0.6 seconds, making it less aggresive.
This results in a 90 second max timeout, which gives more problematic exists a lot more time to cleanly exit.

Begin adding support for getting and handing read lock failures.
Read locks attempts will be in a loop that checks main thread enabled as well.
The timeout is longer than write locks to reduce the CPU overhead as there will be a lot of read locks.
Follow up work will utilize this read lock status handling.

Remove the additional thread enabled check that follows a write lock.
The write lock already checks if the main thread is enabled.

Update: f_thread_lock_read_timed() should return F_resource_not.

The pthread_rwlock_timedrdlock() potentially returns EAGAIN.
This needs to be handled, translated into F_resource_not (with error bit), and then returned.

Update: handle asynchronous failures for failsafe, update locks, and related fixes.

The failsafe needs to be triggered when a required but asynchronous process fails.
I originally planned on implementing this via locks but I would rather avoid adding even more locks.
This approach instead provides a wait loop at the end of the entry waiting only on all required processes.
If any of these fail, then the wait will return the requirement failure.
This is a change to the wait all function and behavior, which is updating to now return statuses.

Get rid of process->status, it is no longer needed now that process->rule.status exists.
Having it remain is wasteful and confusing.

The entry processing is updated to be failsafe aware.
This now potentially operates the failsafe rule item.
The failsafe must not do a wait all like normal operation inside of the entry processing function.

There are some discrepancies between "process options" and "rule options".
Technically, there are no "options" on a rule as this is a concept introduced for/by entries.
The process uses these options but most of them were named "rule options".
I then later created a "process options" to add override so that even if the rule is requested asynchronous, if a dependant thread is requiring it, then it will instead run synchronously in the thread of the depending process.
This resulted in both "process options" and "rule options".
They really are the same, so instead remove the current "process options" and rename all "rule options" into "process options".
There are now no longer any "rule options".
I then renamed the "process options" variables to "force options".

Remove signal_all from delete process.
The signals should now all be timed and will exit when thread disabled is set.

The execution used to be designed with the intent that is where the asynchronous processing would handle.
After multiple iterations in design, this is no longer the case.
Update the code to always pass parameter option fl_execute_parameter_option_return instead of doing it only for asynchronous processes.

Add missing re-locks.
Some of the functions require that a certain (read) lock be held prior to calling the function.
When the function returns, the expected lock should still be held.
It so happens that this is not consistently the case.
Certain error or exit states are returning without re-establishing the expected (read) locks.

The controller_rule_find() returns a boolean and not a status with potential error bits.
Fix a block of code where it is checking for error bit on the return value of this function.

The controller_rule_read() also returns a boolean and is being handled as a status with a bit.
In this case, change it to return a status given that this make more sense in this particular case.

Remove relevant/related stale code and add missing comments.

Update: f_thread_lock_read() should return F_resource_not.

The pthread_rwlock_rdlock() potentially returns EAGAIN.
This needs to be handled, translated into F_resource_not (with error bit), and then returned.

Progress: controller program, implementing failsafe.

Minor code cleanup:
- Removing no longer valid documentation.
- Cleaning up syntax, such as spacing.
- Updating documentation comments.
- Pass controller_main_t as a pointer in the entry function, updating all uses.
- Remove @fixme for considering status handling because I don't plan on bothering with this now.

A lot of the controller_print_unlock_flush() calls are using the incorrect stream.

Use status_lock as a return in cases where the status that is retuned shouldn't become lost when processing the locks.
Otherwise, the errors may never properly bubble to the parent and therefore may never trigger the failsafe.

The failsafe is not a rule id, but instead an item id.

If and when failsafe support is enabled, trigger it.
The currently implemented code only handles synchronous failures.

Begin work with adding a "failed" flag so that asynchronous, but required, failures can be detected for the purposes of failsafe execution.

Update: add comments, fix action type error reporting, and fix entry documentation.

Be consistent and add comments when dealing with nanoseconds.

Action types "consider" and "rule" should be the ".. or more.." error messages.

The entry documentation should be using the word "need" and not "require".
Improve wording.

Update: properly process and support -c/--control custom control group file path.

This is a directory path to the sysfs cgroups directory.
It must end in a path separator '/'.

There is existing code that needed to be updated to use the -c/--control.
It was being ignored!

Cleanup: fix parameter order of fl_conversion_* functions.

Cleanup: remove "local" workaround in execute function.

At the time I was unable to determine the cause.

Now, I strongly suspect it was due to the way threads were being created on the parent stack and the child threads could not access them once a resize function happened.
The resize can, on occasion (and likely more often than not), relocate the address location of the range (array).
This relocation in memory likely caused the weird memory behavior.

Now that the memory is allocated such that the it is an array of allocated pointers, the memory addresses should not change when the array of pointers is resized.
The address to the pointers might change, but from the perspective of the child threads, they don't exist or otherwise matter anyway.

Removing the work around cleans up some clutter and what is essentially a waste of resources.

Update: cleanup @todo/@fixme that no longer matter and implement multistep thread wait timeout.

Bugfix: validation is not processing dependencies.

There is a return statement that must no longer be there.
Make sure to always pass the validation bit.

Bugfix: test mode (-t), should be simulating not executing.

The rule_options is setup but it seems that I forgot to actually pass it.
Set the controller_process_option_execute on the rule_options and then pass rule_options instead of directly passing controller_process_option_execute.

Bugfix: child process PID is not being passed properly and child process prints failure message on terminate signal.

The child process PID was not being assigned because the wrong variable was being passed.

The child processes should not present error messages on exit when termination signal is received.
Make sure that when the child process exists and the main thread is disabled, exit with F_signal.

Bugfix: main process doesn't always exit.

Remove stale lock and unlock that was used for testing or experimentally.
This was causing it to wait for something that would never release the lock because it was closed resulting in a deadlock and the main process hanging on exit.

Bugfix: rules not properly handling status.

The status F_known_not was incorrectly being treated as busy.
Make sure to guarantee lock and then unlock of the process_other lock (read lock) to prevent execution of dependent rule while analyzing state of dependent rule.

Read the rule's status after executing from the rule in the rules array and not on the process.
The rules on the rules array is updated after execution but the process is not guaranteed this.
The status of process is generally reserved for the process to manage the status and not to represent the rule status.

Expanded the example serial execution test entries and rules.
Add a new alternative serial so that one uses normal execution and other uses dependent execution (execution is executed by something depending on it rather than being directly started via the entry).

Bugfix: nanoseconds should become seconds when a second is at least reached.

When adding to nanoseconds would result in a value greater than or equal to a second, instead increment by 1 second.

Progress: controller program.

I completely overlooked that the thread time related functions are relative to the absolute system clock.
The timed locks were all acting crazy because I used relative values!

The process status is not being initialized, resulting in invalid and error prone checks.

Begin fixing problems with the asynchronous processing.
Between incorrect uses of times and some stuctural problems, the asynchronous behavior was not operating in the order of the dependencies.
The current work fixes that, but there is still more work to do.
I expect this code to not work just yet.

There also seems to be a locking issue somewhere in here that prevents the program from fully exiting.
Check the thread conditions as those have had problems in the past.
.

Update: Finish implementing the thread condition functions.

It looks like the f_thread_condition_wait() f_thread_condition_wait_timed() functions were not fully written.
Add missing handlers.
The f_thread_condition_wait_timed() was even missing the return case of F_time!

Update the comments as the "time" value is relative to the absolute system clock time.

Add F_dead, F_live, and related.

Bugfix: improve cancellation point processing and handling.

This avoids the use of f_thread_cancel_test() which is horribly limited in design.
Because f_thread_cancel_test() never returns when thread is in cancelled state, the caller cannot properly handle the situation.
This limits the code design in order to properly use f_thread_cancel_test().

There are already cancellation points in place due to the extensive use of thread.enabled.
Improve these cancellation points, adding timed checks to write locks to further check if a cancellation was received (via thread.enabled).
The timeout is arbitrarily pick as "0.1 seconds".
Hopefully, this doesn't make things too busy, but really the write locks should (ideally) never have to be waiting that long anyway.

Remove stale code in private-common.c involving a write lock and then an immediate unlock on deallocation.

Add additional thread.enabled checks.

There were some places where cancellation points were being returned but were not properly unlocking all held locks that are within the scope of the function.

All threads should now be set to PTHREAD_CANCEL_DEFERRED.

The forced thread termination via kill signals are now removed.
They shouldn't be needed now that cancellation (should be) guaranteed.
This will have to be tested over time to confirm the truth of.

Update: handle POSIX compatibility automatically in f_thread_cancel_state_set().

The POSIX standard does not explicitly define that this parameter can be NULL.
To prevent any possible problems, allow NULL but when NULL is received, use a temporary variable in its place.

Bugfix: thread exiting issues and related.

My attempt to add locks to make helgrind ended up backfired on me.
It seems that when an interrupt is received, the cancel is being sent and it happens at any point in time.
Which includes when locks are opened.
When an interrupt cancels a thread with an open lock, that lock is never closed.
Then, using the same locks to handle cleanup of threads resulted in an occasional deadlock.
Remove all locking in the main thread.
The logic should be safe as the only cases where there might be a conflict, a f_thread_join() is in protected between them.
The cancel function should avoid locks to, where possible.
I am somewhat more nervous about this case, I need to review and confirm if main->thread->processs.size does not change.

I previously updated the force cancel exit thread to use waits and locks.
It later dawned on me that I could just get rid of the force cancel exit thread entirely and implement the same functionality in the cancel thread.

Update: redesign forced exit to utilize timed waits.

Update: lock handling tweaks.

Move the rule lock to inside the if condition block because part of the rule is still being read.

Add missing unlock for other process active lock before break.
Relocate the other process active lock in some cases to be after the last access to the rule.

Utilize process r/w locks around starting and joining the main threads.

On exit, check to see if id_exit thread is actually used before attempting to join it.

Progress: controller program.

Copy over the rule item action statuses when the rule process completes.

Update cleanup thread:
- deallocate rule data in no longer used space.
- make sure cache thread is being started.

Implement asynchronous example rules for testing.

Disable asynchronous execution when running in validation mode.
This ensures consistency and cleanliness when outputting the validation data.
There is no reason to run asynchronously in this mode because nothing is supposed to be run anyway.
Make sure that execution (simulated or not) is not performed in validation mode.
Make sure the program immediately executes at the end when in validation mode.

Workaround: weird print data when received by a pipe.

Not sure what is going on here, but it seems that the data is not correctly printing via pipes.
Add a flush before unlocking the print locks as workaround.

Cleanup: rename controller_rule_simulate() to controller_rule_validate().

This function is actually for the "validation" part of the simulation.
Changing the name makes it less confusing and more semantically accurate.

Progress: controller program.

Update some of the comments.

The "consider" was not being loaded into the "process" array.
Change the behavior to allow for loading the "consider" rules into the "process" array without executing them.

Fix a bug where some entry items were being skipped.
The counter was being added an extra time during the loop, resulting in the skip.

The child processes are not exiting cleanly.
The state F_child was not being fully bubbled up the call stack.

It seems that when forking within a thread, the forked child process, on exit will not result in the thread returning to the caller.
For now there is 1 block (according to valgrind) that is "possibly lost" for every forked child process.
A more in depth investigation is needed.

Add a stub for an asynchronous entry that I will be writing for additional testing of the asynchronous processing.

Cleanup: printing and stale code.

Structural problems related to printing.
Relocate how the final newline being printed on simulate is structured in the code.

Remove stale "simulate" variable that is no longer used.

Update: add pthread semaphore support and correct comments.

This includes named semaphores, using the words "semaphore_file".

Fix several problems with the comments.

Update: controller program should immediately exit when doone after validating.

When in validate mode, the controller progam should not sit and wait but instead should immediately exit.

Update: controller program should continue on error.

Except for certain error codes, like out of memory, record errors and continue onward.
Future versions should somehow handle out of memory issues if this program is to become an "init" replacement.

Avoid unnecessary assignment of rules error status.
In some cases, the rules error status was being assigned twice.

Update: add message when done processing entry.

Bugfix: wait condition issues, memory addressing issues, and exiting issues.

The thread conditions, when waiting, may never stop waiting.
Switch to a timed wait, allowing for the condition to determine if it should stop waiting.
I attempting to signal the waits on exit, but this didn't work (however, this will still signal on exit).

Make sure to join all threads, add a failsafe thread join in the process delete function.

The array of processes is a single array.
When this array gets reallocated (resizing to a larger size) the memory addresses may change.
This is a serious problem in that the threads are using those addresses and they suddenly change.
The threads have no way of switching to the new addresses and memory problems happen.
Redesign the array of processes to an array of pointers to processes.
I considered using a block structure, but decided to keep it simple for now.
The downside of this is that on every resize, there must be another allocation for the process address being pointed to.
In the future, I may consider switching to a block structure where I allocated multiple blocks at a time, while still using pointers.

Rename "id_process" to "id_child" to avoid potential confusion between "processes" and "pids", given that I am using "process" with a very different context in this project.

Update all timeouts to be stored in macros.

The cleanup and exit functions were deadlocking, change the locking usage in these functions.

Add missing increment at the end of the loop when processing entry items.

Bugfix: asynchronous processing is not working in controller program.

This is because I accidentally passed a pointer of a pointer instead of the pointer itself.

Progress: controller program.

Update: don't use WUNTRACED | WCONTINUED by default, provide "wait".

Don't have waitpid return if child stopped or continued.
Instead, provide a "wait" property to pass to waitpid().

Progrress: controller program.

This gets the program back into a semi-working state.
I've tested the threading and the previous threading problems appear to be gone.
That tells me this massive rewrite/redesign seems to have been worth it.

There is still a lot more to do:
1) Something is not being shutdown properly, on exit (using the control-c termination signal with -t passed to it).
2) The simulate parameters are no longer working (oops!).
3) The printing appears done, but I've confirmed some problems due to design*.
4) I have not done extensive tests, so there may be other regressions.

* As for the case of #3, the problem is with printf() (and fprintf()) and threading:
- The child processes will write to stdout and stderr.
- The controller program also writes to stdout and stderr.
- printf() and fprintf() guarantee locking, but this doesn't help between different executions.
- Writing one massive complete fprintf with, say 20 parameters, is ridiculous.

This leads me to believe the best solution is to write my own printf/fprintf replacement...which is a huge task.
If I do this, then I can get rid of all of that print locking and use the locking provided by the custom functions.
The difference being that these locks would be designated by another, special function, so that the locks can be held across function calls.
The other advantage would be being able to add support for many of the specialized FLL structures (particularly color printing).
The downside is I would need to do a lot of research in witing to the terminal (the putc() and similar stdio functions) and bufferring.
I would then have to handle all of this!
Which is a huge amount of work.
So, for the time being #3 will be ignored and left as a design flaw (or more accurately a design limitation).

Progress: controller program.

Progress: controller program.

Bugfix: fix thread initializers and add documentation on thread allocation requirements.

The PTHREAD_ONCE_INIT cannot be deleted.
The pthread_spinlock_t cannot use PTHREAD_MUTEX_INITIALIZER, so instead use ((pthread_spinlock_t) 0xFFFFFFFF).

Many of the thread structures require dynamic initialization.
Document this behavior.

Progress: controller program.

Progress: controller program and related.

Use "copy" instead of "clone", it seems more accurate given that the code is not guaranteeing the same exact memory structure (only the data is guaranteed).
I believe that I need to document my "completeness principle", documenting the structures and what needs to be done.
I also need to document the exception cases.

Implementing the rule copy function, I realized that I need to have the copy function and not just utilize the "append" functions.
There are many functions where "append" does not make sense.
This means that "copy" must be part of the completeness.

Comment out the cache clearing code.
I will probably get to that part last.

Cleanup: document _di_pthread_support_.

Provide simple "defines" documentation for "_di_pthread_support_", even though its technically not used in that project.

Bugfix: recently added capability functions are from newer version.

The libcap project hasn't been updated in a long time.
Apparently, somebody relatively recently picked up the project and started maintaining it.
This introduced newer functions.

For some reason, my system has a hybrid of this.
The headers show the newer functions but the libraries lack them.

Add a new define "_libcap_legacy_only_".
Enable this by default given how long libcap has exist unchanged.

I also noticed and inconsistency with the function names for users and groups (which are newer functions).
Rename them to not include the "_id".
Remove a duplicate function that didn't even have a reference in the header (oops!).

Update: capability.

Add missing typedefs and cleanup ordering of typedefs.

Add several more functions.
I found more functions than what are implemented now.
The problem is my current systems manpages don't easily find them (such as cap_new_launcher, cap_iab_init, cap_iab_get_vector, etc..).
I will not implement this for now and will need to do some research to see what they are.
Some functions are documented in the manpages as deprecated or obsolete.
I would rather not want to implement any of the deprecated or obsolete functions.

Make sure all "implemented not" functions still do parameter checking.

Use "clone" instead of "duplicate" to be more consistent with the terminology used in this project.

Add additional documentation.

Feature: support f_string_constant_t as a way to pass "const char *" as a parameter.

The parameter will have the return value and needs to be a pointer.
Passing "const char **", the "const" is applied to "char **", which is not what is wanted.
The desired logic is "(const char *) *", but that is not valid syntax.
To achieve this, "const char *" is turned into the typedef "f_string_constant_t".
This allows for "(const char *) *" to be used in the form of "f_string_constant_t *".

This is a special, exceptional, case and there are no plans to support an "array of" or any of the completeness practices.

Update: f_capability improvements and cleanups, and provide f_implemented_not status codes.

Provie F_implemented and F_implemented_not, then use them for capability function support.
This now replaces F_suppoted_not for this particular usage, allowing f_supported_not to be used more naturally for other purposes such as representing codes used by the POSIX libc standard.

Cleanup the documentation comments, updating to the latest style.

Add some missing capability functions (I think there are a lot more to do, so another commit will eventually follow this one).
A number of the status codes were incorrect and/or undocumented.
Make sure F_parameter is handled more consistent (adding it where it is missing).

My increased experience with the POSIX libc standard has led me to believe that it is not safe to use (XX < 0) comparisons when comparing for -1.
This is because POSIX libc is often more loosely defined so if it says -1, that allows for all other negative values to be implementation-specific.
By checking for (XX < 0), this would expose this project to potential implementation specific bugs.
This likely needs to be fixed everywhere, but for now f_capability is where I am starting.

A new function f_capability_supported_ambient() is provided to handle the CAP_AMBIENT_SUPPORTED() macro function.

Update: add documentation about return codes.

Progress: controller program.

Update: update utf string with string changes and fix problems with string.

Synchronize the utf string with the latest string changes.

I noticed that some of the disable macros are not used and should be for the private functions.

The *seek* functions needed to be fixed in string.
Add a missing *seek* function.

Update: add "eoa", add append functions, relocate f_string_dynamic*, and update comments,

"eoa" or "End of Array" is being experimentally added as a compliment of "eos" or "End of String".
Remove stale status code from before I fully embraced error and warning bits.

Add more append functions.
Make existing functions more consistent, checking for array overflows, returning F_array_too_large when appropriate.
Update the comments while I am at it.

Relocate the f_string_dynamic_* functions in string.h and string.c to string-dynamic.h and string-dynamic.c, respectively.
This requires that the string_dynamic.h header depend on string_range.h

Bugfix: should be using level 0 parameter checker macros in level 0.

Update: implement append functions for array types and implement all the other functions.

Start implementing all of the macros as real functions for these.
Macros do what I wanted and save writing code, but the binary size is more of a concern.
Switching to explicit functions should also make debugging easier.

The macros may be removed eventually and all of the code utilizing the macros will be updated to use these.

There will be more changes like this going forward in some other projects like f_string and f_utf_string.

Cleanup: use 'print' instead of 'error' for variable name.

Update: add done, empty, and full status codes.

Include the respective "not" codes as well.

Bugfix: more thread macros aren't correct.

Progress: controller program.

Continue working on the thread support.

There are considerable redesigns being implemented.
The code is currently in an inconsistent state.

Update: replace f_string_length_t (and related) and miscellaneous cleanus & fixes.

The f_string_length_t, f_string_lengths_t, etc.. types are somewhat redundant.
Simplify the code (reducing binary size as well) and just stick with the f_array_length_t types.

Miscellaneous documentation cleanups.

Progress: controller program, address issues with invalid reads/writes.

I have finally identified the cause of the confusing invalid reads/writes.
It seems that using the pointers to memory address directly associated with the thread data and then accessed within a fork() call is a problem.
By copying the data to variables local to a function and then using that memory address, the read/write problems go away.

This commit only performs an immediate fix for the current problem.
What I really need to do next is to rewrite/restructure much of the code with this behavior in consideration.
There were a lot of experimental changes I performed while trying to identify this problem.

There are still some additional locking and other thread problems to solve.
These will hopefully be fixed by the planned rewrite cleanup that I need to do.

Progress: controller program.

Continue working on the thread support.
As I am learning how to use threading, I am finding that my conversion is flawed in some way and somehow losing the pointer address.
I worry that this might be related to how realloc() changes the pointer address, but there is no strong evidence to this fear.

I've decided to just save the current state (regardless of its state) and will rethink the design.
Currently the behavior is more consistent but still problematic.

Update: memory function tweaks, update thread code, and improve execute functions.

Restructure the memory functions a little.
Add comments about realloc() potentially changing the pointer address.

A few of the thread type macros are missing semicolons.
Remove f_macro_thread_mutex_t_clear().
There are likely other thread types that cannot be set to 0, and they will be correct as I discover them.

Rename the thread condition block and unblock functions.
Add missing f_thread_detach() implementation.

The execute fnctio fll_execute_program() should use pid_t when returning a PID.
This is potentially different from int, so instead use a void * and cast to an int * or pid_t * as necessary.

Cleanup: don't re-use 'result' variable name, and fix documentation.

Update: remaining thread functions and add f_recover (and f_recover_not) status codes.

Implement the remaining POSIX thread functions that I am aware of.
I took a break in the middle of writing some of this so I expect there may be some mistakes resulting from such an interrupt.
I do not feel like focusing on this now and will address any problems as I discover them.

Progress: controller program and f_thread.

Add more mutex lock protections.
The thread->data->child is shared and cannot be used as a per thread child process storage, so comment out and add an @fixme.

In the case where the exec() functions return in the child process, the mutexes may not be fully trusted.
All the child process should do is find its way to the exit, deallocating along the way.
Avoid all mutex-related and printf() related functionality where possible.
There were some places where the F_child is not being checked for and returned on but should be checked for and rreturned on.

Work towards improving the mutex locking logic when working with the asynchronous processes, caching, and cancelling.
There is more work to do in this regard.

Sleep interval for the cache cleanup thread now uses the short timer when in test mode and the long timer in non-test mode.

Add a list of functions that need to be completed for t_thread.
Add f_thread_mutex_attribute_t and f_thread_mutex_attributes_t related functions.
Minor cleanups in f_thread.

Progress: controller program and related.

Add f_signal_send().
Cleanup some of the f_signal code.

Add "return" mode option to fl_execute.

This adds more thread related changes, much if this I am semi-experimenting.
I will likely do a post review and try to clean it up and remove anything unnecessary.

One thing in particular that I am trying is saving the child process PID for a foreground process.
This can then be manually sent a termination signal on exit.

The program should exit in certain validation modes.

Cleanup f_environment logic in one function.

Update: add missing thread functionality and fix an initializer.

Progress: controller program.

Wrap all print functions that print while any threading is in used with a mutex lock.

Add controller_execute_set_t to shorten the execute function arguments.

Add missing f_gcc_attribute_visibility_internal.

The controller_rule_read() inside of entry does not need to be read locked.
This operation happens before any threads are started.

Replace simulate argument with options argument for execute functions.

Add more verbose output in the simulation for the execute operations.

Cleanup: macro functions should have 'macro' in their name.

Bugfix: thread delete functions and related.

Bugfix: incorrect data type being used.

This should be f_array_length_t and not f_string_length_t, for array lengths.
There are some cases where the string length is using f_array_length_t, which ironically should be f_string_length_t.

Progress: controller program thread support.

This is the initial pass at getting the thread support implemented.
There were several necessary changes in how the cache is defined and used.

This is very much incomplete.
All of the printf functions after a certain point need to be protected by a print mutex.

I need to figure out if and how to handle child processes from an execv() call from inside a thread.
Ideally it needs to gracefully exit and cleanup resources in the child process.

Just like with the child process and execv() the signal/interrupt handling needs to be handled in a way that gracefully exits as appropriate.
Prior to adding thread support, I added signal support and tested that it works.
These interrupt signals work but have not been tested or reviewed now that the threading is added.

A quick execution of this code shows that there are invalid reads (and therefore segfaults).
I need to pick up here and make sure all of the resources are being properly managed.

Bugfix: missing semicolon, missing macros, add todo, and remove extra errno check.

Add a missing semicolon.

Add the delete macros that are missing.
After looking at this, I noticed that I will need to call these delete macos, so add a @todo to designate that a series of memory management functions need to be written for this.

The ETIMEDOUT is not valid fo the f_thread_create() function.

Cleanup: comment for memory function.