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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.