× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



At 11:30 AM 10/19/01, Buck Calabro wrote:
> >You might find it easier to program what you want in C.
> >
> >RPG has poor support for threads, and so C is the better choice.
>
>Thanks Hans!  I'll have to get Papal dispensation to use C.  Yeah, I know -
>use the right tool for the job.  I agree completely but my hands are tied
>with language choice.

If you must stick with RPG, consider the givedescriptor / takedescriptor
API's.  I was easily able to _simulate_ a multi-threaded server by having
an RPG 'manager' program listen on a socket in a loop.  As connections are
requested, the manager program uses givedescriptor to hand off the
connection to a waiting 'worker' (batch) job which services the
request.  The manager is then free to go back and listen on the socket.

The only interesting tidbit is that Givedescriptor needs to know which job
to pass the socket to.  As each worker job is initially submitted, I have
it send it's information to a data queue.  The manager job reads the data
queue and uses that information in the Givedescriptor call.  Upon initial
startup, and whenever a worker job finishes up servicing a request, it
issues a call to  takedescriptor, and then submits its information again to
the data queue.

The advantage to this method is that when there is no activity, little
system resources are consumed in a 'select' type loop.  The manager job
blocks while it is listening, and the worker jobs block waiting for
takedescriptor.  It's also fairly simple to code in RPG.

The disadvantage is that each worker thread is not a thread, but a full
blown job.  If you want to work with hundreds of clients, I suspect having
a job for each one might not be terribly efficient -- a thread in C may be
a better choice.

Regards,
Rich



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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.