Yeah, for many tasks just spawning another job is much easier and
cleaner. It also is much less error-prone. One of the biggest problems
with multi-threaded programming is that you can accidentally do
something that's not thread-safe and not realize it or catch it during
testing. When it comes up in production, it's almost impossible to
tell what happened. So wherever practical, just spawning a new job is
better.
So there are really two situations where threads make sense:
1) When the different threads/tasks need to share data between them.
2) When the performance of spawning a job is unacceptable. This is
highly unusual, and doing something like starting worker jobs in
advance, or using prestart jobs can often be a solution -- so I will not
discuss it further, I will leave that discussion to the remainder of
this thread :-)
When you need to share data between threads, though -- this is where
threads shine. For example, if you are writing a chat application where
users can all send each other DMs, there's no practical way to do that
with spawned jobs. In that case, you will have variables that are
shared between the threads -- but you cannot just read/write those
variables, you need to serialize access to them. Otherwise you can run
into thread safety issues.
To deal with that situation in RPG, you can encapsulate the shared
variables in a thread(*serialize) procedure. This is super easy to
do. To deal with it in C, you typically would use a mutex to serialize it.
You say "you can use *serialize but that means all the other threads are
shut down" -- that's not exactly true, they're only blocked (which is
what I assume you meant -- not really "shut down") when trying to access
whatever has thread(*serialize) on it. In C, you would do the same
thing with a mutex, and they'd be blocked the same way. So it really
it's really the same situation.. the only difference is that
thread(*serialize) is a lot easier to code than the pthread mutex API.
If you were required to use thread(*serialize) on EVERYTHING, then I
could see your point -- but, you're not. You can code some procedures
as thread(*serialize) and others as thread(*concurrent). The
*concurrent ones work exactly like the code you would've written in C.
So the only difference is that you can choose to use *serialize to
encapsulate data that must be serialized, vs. coding the mutex api.
That's why RPG is easier.
I get the feeling, based on your comments in this thread, that you
haven't looked at the thread support that IBM added to RPG back in V6R1,
and are still using the understanding you had from the V5 days when
thread(*serialize) was the only option.
Also, I find the term "socket server" frustrating. It's not serving
sockets... Aside from RPG programmers, nobody calls them "socket
servers". Most people would say their writing an "FTP server" or "HTTP
server" or INSERT-WHATEVER-NETWORK-PROTOCOL-HERE server... or whatever
it happens to be. The name explains what type of service you are
performing. Sockets, on the other hand, are just an API that your
program uses to communicate with the OS. They aren't something that's
being sent out of your program... so they aren't being "served".
On 10/27/2021 2:00 PM, Alan Campin wrote:
Yes, I agree that you can use *Serialize but that means that all the other
threads are shut down until processing is completed for that thread. I have
processing that needs to be done. I have no idea what processing or how
much time that processing will take at the time I write the socket server.
That processing might take 10 seconds, it might run for 10 minutes or an
hour. Completely unknown which is why I want to run that processing in a
pre-start job.
Now looking back at the project, it is a whole lot simpler to write it in
RPG and just do a spawn of another RPG job. That RPG job handles the
network communications to the client and runs the processing. Pretty
simple. I did it in C but that was fairly complex. It took me weeks of work
(My own time) to figure it out but in the end it worked. Then I went back
and wrote in RPG. A lot simpler but in both cases I still had the same
problem. In order to publish the project, I felt I would need to
encrypt the communications and that just seemed like a huge problem so I
gave up on it.
midrange.com
