kinner@wsucshp.UUCP (Bill Kinnersley ) (05/19/87)
(I'm running about two months late..this has been a busy semester) In article <2679@well.UUCP> ewhac@well.uucp (Leo 'Bols Ewhac' Schwab) writes: [in a discussion of messages and replies thereto] > For the sake of completeness, Intuition is a totally > different animal. Intuition is not an I/O driver, it's a sort > of application. You don't send requests (messages) to > Intuition, Intuition sends messages to YOU. That's why, when > you get an IntuiMessage, you should reply to it as soon as you > can.. It's a different animal, I'll grant you that, but it's not even "sort of" an application. The way I understand it, Intuition is a library. Nothing more. It is made to have the appearance of an independent task, but only because it is called at such frequent intervals by other system tasks. Mostly by the input.device, which calls the entry point Intuition() and supplies a stream of input events. Intuition() turns some of these into IntuiMessages. Messages and ports are designed to handle communications between two exec tasks. Intuition appears to act as a task when it sends you a message to your IDCMP UserPort and you have to send it a reply, but that's a fake--it's all done with mirrors. Take a look at the contents of an IntuiMessage. The Reply Port for the Message is the other IDCMP port in your Window, w->WindowPort. But the SigTask is NULL, and the Flag is IGNORE. There *is* no Intuition task listening on the other end, and your faithful replies to Intuition are just being enqueued. Presumably Intuition() has to scoot around and poll all these ports itself as part of its own housekeeping. In fact, Intuition implemented as a task would quickly run into problems. In the first place, someone would surely be tempted to RemTask() it. Secondly, since there is a limit of 16 signals available to each task, there can only be allocated 16 different Message Ports at once, hence Intuition (if it were a task) could manage only 16 windows. --- "Nesting is for the birds" --Bill Kinnersley USENET: ...!ucbvax!ucdavis!egg-id!ui3!wsucshp!kinner INTERNET: kinner%wsu@RELAY.CS.NET CSNET: kinner@wsu MAIL: CS Dept, Washington State Univ, Pullman WA 99164-1210 PHONE: (509)332-3340
dillon@CORY.BERKELEY.EDU.UUCP (05/21/87)
>into problems. In the first place, someone would surely be >tempted to RemTask() it. Secondly, since there is a limit of 16 >signals available to each task, there can only be allocated 16 >different Message Ports at once, hence Intuition (if it were a >task) could manage only 16 windows. Of course, if somebody RemTask(), say, one of the trackdisk processes, he would certainly crash the machine also. Well, actually, there is no reason why (if it were a task) Intuition couldn't simply allocate a single reply port and have messages from all windows replied to that one port. This is sort of what DME does (though from the opposite direction). It can be done because each IntuiMessage contains a window pointer field so you know to which window the message applies. It is interesting to note that it has been commented that the graphics library should properly have been a device (so you could do line/ blitter stuff in parallel with calculation in a given task). -Matt
andy@cbmvax.UUCP (05/22/87)
In article <8705211835.AA20920@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > It is interesting to note that it has been commented that the >graphics library should properly have been a device (so you could do line/ >blitter stuff in parallel with calculation in a given task). And Intuition has long desired to become a device, so it may safely take input from other tasks than the input task. But time pressures way back when prevented it. (Ask RJ about time pressures) And IntuiMessages shoud equal InputEvents, but that's another story. andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga "An end is always a new beginning." - Captain Cloud Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.