[Tutor] Re: event-based programming

[Erik Price]

Sean & dman,

Thanks very much to both of you for addressing this question.  I now 
know two things about event programming:

1) In theory, event programming works by the event handler subscribing 
to a "service" which does the work of sending events to the handler.
2) Most of the time, the details of how this happens is tucked away in 
low-level code that the average programmer doesn't have to worry about.

Although I really wanted to know "what is going on", so the first answer 
was very helpful, the second one assures me that, as with JavaScript 
event handling in a browser, the programmer doesn't have to worry -too- 
much about the mechanics of event programming.  Just write the event 
handler, register it somehow (though this seems to be done for you in 
JS), and then write the code that submits the event (also something the 
browser does for you in JS).

Of course, this leads to further questions, naturally.

On Saturday, July 13, 2002, at 02:11  AM, Derrick 'dman' Hudson wrote:

> Note - this is not real code, but it gives the idea.
> It is sort of a blend of the Java/Swing and GTK+ styles of
> implementaiton since those are the toolkits I've written the most code
> for, though not recently.  (actually, those are the only toolkits I've
> written applications for.  The two xforms labs don't really count, and
> I've only glanced at wxWindows)

I did not see a Swing library in my module directory.  Is this a 
standard offering with Python 2.2?

> This leads to another problem, though.  What if the main thread (event
> loop) and the worker thread both try to update some component of the
> gui at the same time?  A race condition.  Then add modal dialogs to
> the picture (modal dialogs are evil anyways).  One of the bugs I fixed
> at my last job (involving java/swing) was a total lockup of the gui
> under certain error conditions.  The problem was just that -- a worker
> thread tried to display a modal dialog.  However, it happened that
> that caused a deadlock in the system (without the dialog ever
> finishing painting).  The solution was quite simple -- wrap the
> dialog's creation in a "Runnable" object and queue it for execution in
> the main thread.  Swing has some utility functions
> (eg javax.swing.SwingUtils.invokeLater()) that allow you to pass a
> java.lang.Runnable object which will be added to the end of the event
> queue.  Then the event loop will run() that object (call its .run()
> method) in the main thread.

I'm sorry, but this is confusing to me.  Although I'm not sure exactly 
what a modal dialog is, I follow what you are saying -- but I don't 
understand how the modal dialog locked up the gui.  By putting the 
dialog's cretaion into a "Runnable" app, I am assuming that this means 
you coded it to be performed within a separate thread (perhaps this is 
what you were talking about by "spawning a 'worker' thread"?).  But what 
I am unsure of is what is wrong with having the dialog just come up (the 
way you had it originally).  This is very interesting to me, learning 
about this topic.

> An additional reason all this is necessary is because most (all?) gui
> toolkits are not written to be thread-safe.  That is, they don't
> provide any internal locking or synchronization; meaning that they
> assume they will only be accessed from a single thread.  This is done
> because locking and synchronization adds both time and memory
> overhead, and for some applications it isn't necessary.  In addition,
> if you follow the guidelines I outlined above (as the swing utility
> functions make it fairly easy to do), you can avoid the issues
> altogether and not having the speed/memory overhead is a good thing.

You mean by putting the code into a new "Runnable" instance?  I have not 
yet learned about the "Runnable" object yet.

> To summarize, event-driven programming consists of defining functions
> or methods that will be called when an event occurs.  How events are
> detected and handled is an implementation detail of the underlying
> system.  Suffice it to be "magic" that is well documented.
> Event-driven programming (at least in GUIs) tends to be seen
> hand-in-hand with parallel processing, and all the synchronization
> issues that entails.

That is reassuring for now, though perhaps someday I should look into 
that implementation and see how it works.  Not at this early stage, 
though.

I have one last unrelated question.  You (and many other sages on this 
list) have experience with Java.  I must admit that, while I really like 
Python, I am trying to learn Java too.  Is there an equivalent 
"tutor"-style list or forum for Java programming?  I have not found it, 
despite everywhere I look people are saying that the Java programming 
language has a large user base and support community.

Thank you very much,


Erik