Leonidas Savvides wrote:I am currently Reading How To Program JAVA 7e, DEITEL, Well in 3 small chapters I will reach Threads Chapter, this book is it for me (main language JAVA)? Are you recommend after this chapter read your book? Your book is it in color, two colors or b&w?
In a GUI Desktop App theading matters[desktop pane_java], well every window is a thead or not required eg is a photo?
I haven't read deitel's book myself, but I guess sure, why not :-) My book is B&W except for the cover.
In the GUI programming there is a difference between window objects, what is shown in them, and the threads. My GUI experience comes mostly from the times before threads.
The window is a rectangle (sometimes stenciled to a more strange shape) that is a
unit of commutinaction between the program and the windowing system. The windowing system sends the user input events associated with that window. An dthe program sends the drawiing requests, such as drawing a photo or an image of a button in a window. The windows are fairly cheap now, there can be hundreds of them in a program. However there is still a cost to them. A browser displaying a page with thousands of buttons (most of them invisible at the time, and becoming visible only by scrolling) would probably not make a window for each button. Instead it would draw the images of the buttons in the same window.
The threads are even more expensive than windows. So in the olden times there was one
thread, receiving events from the windowing system, and dispatching them to the handlers in the objects owning the windows. Nowadays there may be multiple threads in a pool, or more likely still just one thread per each top-level window, with the events for all its subwindows happening in the same thread.
Where the threads help a lot, is with the background computations. Fitting those into the event handling loop was a major pain in the times before the threads, and now they are easy: just make a separate thread for each background computation. Say, in a browser, when you get a click requesting to reload the page, you don't get the event handling thread stopped by this activity. Instead you just start the page loading thread and let it do its work, while your event handler keeps handling the clicks.
However the background threads add its own problems. Suppose someone clicks a reload, then doesn't wait for the result, types a new URL while the reload didn't complete yet. There's got to be some way to stop the reload thread and not let it spoil the page received from that new URL. So what I try to do in my book is to look at this kind of the problems and show some solutions.
