11.4 "multi-threaded" appserver

it is not part of 11.4. we are still working on it. also, it is not a a "multi-threaded" app server but a "multi-session" app server.

Is it not in 11.5?    Early access for 11.5 has opened, but we haven't seen anything yet.

Ok thanks for your reply. I did quote "multi-threaded" for a reason. Read the comments here by Bruce Gruenbaum about it  ("rocket science" etc) .

fine. i also said "multi-session" for a reason. the nxgas does use operating system threads internally for various things. an app server agent process contains a number of worker threads and handles some other number of concurrent 4GL sessions. Incoming requests (which could be destined for specific sessions if app is stateful, or not if stateless) are farmed out to worker threads fro processing. However, at this time the use of threads is entirely internal to the 4GL runtime. There are no language features related to threading and no new way for session to communicate with each other.

And you wanted to make sure that we didn't get our hopes up about actually getting the important feature of multi-threading! :)

yes. i simply wanted to be clear that these are not the threads you are looking for.

they do make a step in that direction though. before we can go there, there are many important questions that must be answered. in nxgas we have the threading infrastructure internals for the 4GL runtime. but:

assuming you could create concurrent threads of execution is a 4GL program somehow, can they communicate with each other? how? can they share data?

what should the concurrent programming model be like? how do we make it easy? clearly the use of mutexes and similar mechanisms for synchronization are the wrong thing to do -- it is just much too hard to write programs that way. Erlang has it right.

what happens when two threads in the same program update the same data in the database?

etc., etc., etc.

I'm just a lowly developer, but one that happens to have experience with both progress and erlang (as well as elixir), having written a couple of applications in both languages (they both compile down to erlang byte code). I agree with gus that the Actor model of concurrency is the way to go (it's a trade-off between memory usage and the need to use locks).

But, when concerning screen/database changes for a particular program, would it make sense to have a single thread for both, and anytime a screen change or database access/change takes place it sends a message to that particular process? I know that with Erlang, opening a file returns a process id for which you can send messages to. If you pass around this process id to other processes, you effectively have concurrent access to any particular file.

Just thoughts to add to the discussion.

Solomon Staggs

Yes, the threads need to communicate.  They share data by passing parameters, not, I think, by pointing at any common data.  The lock for update is held by the thread, not the session so two threads are no different than two processes.

@TMH: think about this more. then answer again.

Give me something to think about.   I'm not suggesting this is a complete definition, but as attributes in a solution.