Make run_async actually async. Right now it’s just a long-form for run with a server-side results cursor, which as I mentioned ought to be a function of the basic run command. The purpose of async is to allow you to do other things while waiting for the long-running process to complete, and currently you can’t issue any other queries while the async one is running. (Obviously the client program can do other things while the query is running. It’s in a separate process.) Prolog has great coroutining facilities, use them to let you issue multiple queries and let them run independently, or at least sequentially. Use command IDs (or have the server return a query ID in the run_async reply) to distinguish which async_result the client wants to fetch, and then the server can start the engine working on the next result for that query after it returns this one.
I guess I’d argue that run_async is async, from a “the client is not synchronously waiting for a result” point of view, but I see your point.
My thinking here was to keep the interface as straightforward as possible. Each connection represents a thread that can run one query at a time. The async API on a thread allows you to retrieve answers without waiting (i.e. asynchronously) as they are available. If you want to run queries concurrently, you can create a new connection (i.e. thread) and run them concurrently.
I see the benefit, though, of having a way to fire off a bunch of queries on one thread and checking back to see when they are done. Certainly the library writer, or the developer, could each do this at their layer, given what is provided already.
OK, let me think about this a bit, I do agree it is going to be something people will want. One way or another.
From the SWI Prolog board:
I guess I’d argue that run_async is async, from a “the client is not synchronously waiting for a result” point of view, but I see your point.
My thinking here was to keep the interface as straightforward as possible. Each connection represents a thread that can run one query at a time. The async API on a thread allows you to retrieve answers without waiting (i.e. asynchronously) as they are available. If you want to run queries concurrently, you can create a new connection (i.e. thread) and run them concurrently.
I see the benefit, though, of having a way to fire off a bunch of queries on one thread and checking back to see when they are done. Certainly the library writer, or the developer, could each do this at their layer, given what is provided already.
OK, let me think about this a bit, I do agree it is going to be something people will want. One way or another.