× 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.



On Thu, 3 Mar 2005, Steve Richter wrote:

On Thu, 03 Mar 2005 20:25:28 -0600, Vernon Hamberg <vhamberg@xxxxxxxxxxx> wrote:
We must be talking different things here - VB for the longest time did not
have thread capability, yet was considered event-driven. So you must mean
something different.

for event driven programming you need a message loop. Every windows program has, at its heart, a message loop. The Windows OS feeds events like a keystroke, mouse move, a command to close the window to the windows message queue.

on the 400 you dont have that default message loop.  If you want to
use an event model for your interactive job you need threads to
implement the whole thing.  The main thread would receive from the
message ( data ) queue, processing the events.   Other threads would
feed events like "the user has pressed the enter key", a socket
receive has returned some data,  a physical file trigger has fired
because a record has been added to a file.

You don't need threads to implement event driven programs. Indeed, multi-threaded events driven programs are a relatively recent development. X11 didn't start using threads until R6 IIRC (R6 is the current major release). x5250 (an X11 5250 emulator I wrote) is event driven and does not use threads. I would guess that the majority of event driven programs do not use threads. All is needed is a multiplexing function such as poll() or select(). There is no technical reason why an event driven program couldn't be written on the AS/400. Joe's idea of using data queues would work.


All of this is just a big example because display data managment and,
I guess 5250,  does not handle change of direction very well. Once the
display is waiting for the enter key to be pressed, the device is not
available to have a new screen written to it.

Whether this is all true, I am not sure.  I am just using the topic as
an example of what could be done with threads and other improvements
to the system.

The 5250 protocol doesn't lend itself particularly well to event driven programming. Having threads wouldn't make it any better. Threads would probably make some tasks nicer, but database driven apps probably aren't among them. It seems to me that any performance gain by using threads would be lost in all the locking you would have to do to keep the data coherent. Threads work best when you have discreet tasks that can work independantly. The database itself might be able to make use of threads though.


James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw

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-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.