Hello,
Is it possible to complete a transaction without fail in one thread; but then to have an different thread determine failure and rollback the transaction?
thanks,
Dan
No. Transactions are deeply anchored in the thread logic. You can of course have the transaction waiting on some synchronization primitive (like receiving a message). In general though, I’d try to collect all data required for the processing and then start doing the processing inside the transaction. That gets more important when transactions have to check the consistency with the outside world (transaction/3) before doing the commit.
Thank you.
Yes, waiting on a signal could work – although, i guess changes to the KB are not visible to other threads.
It is unrelated but, as is, engines have everything a thread has as well. Only in the single threaded version there are no mutexes for obvious reasons. I’m actually wondering whether or not that is a good idea. Sending a signal to an engine will be pending until you do an engine_next/2 or engine_post/3. It might be better if engines join the signal queue of the thread that runs them. I don’t know whether we want message queues for the single threaded version. Most of all, I don’t know whether we want thread_local/1 predicates to be also local to engines as they are now. Same for Prolog flags. Getting rid of all that stuff makes engines more lightweight and possibly also provides cleaner semantics. As is, they are roughly threads that are allowed to be attached and detached from an OS thread.
Yes, but there are also cases where you don’t want that. For example, Paul Tarau (one of the pioneers using engines/interactors in Prolog) illustrates its use by implementing findall/3 using engines. You would like to have the findall/3 access the thread_local/1 predicates of the thread that uses the engine. He also proposed implementing the suspend for tabling using engines, same story.
A crucial difference is that in Prolog we have dynamic predicates, which are a bit like global variables and we have the Prolog stacks. One of the nice things about engines is that you can have a nice stack based coroutine for one or more threads that may or may not be involved in backtracking.
Possibly an option when creating the engine that tells whether it should use the database view of the thread that is running it or have its own view is enough?