hughesmp@vax1.tcd.ie (06/27/91)
I am writing a module wimp task that must not survive reset, ie it must be rmkilled after / just before a reset/break occurs. Bearing in mind that it cannot call OS_Module 6 (Delete) from within a Service_Reset with guaranteed success, how can it kill itself? I want it to be a module task so that it does not need a whole page to itself. Can a utility (filetype FFC) be a wimp task? Ta muchly, Merlin. --SICK--
snb90@uk.ac.soton.ecs (Stewart Brodie) (06/27/91)
In <1991Jun27.052256.1@vax1.tcd.ie> hughesmp@vax1.tcd.ie writes: >I am writing a module wimp task that must not survive reset, ie it must >be rmkilled after / just before a reset/break occurs. Bearing in mind that >it cannot call OS_Module 6 (Delete) from within a Service_Reset with >guaranteed success, how can it kill itself? I want it to be a module >task so that it does not need a whole page to itself. Why don't you have a flag in your workspace which gets set when a Service_Reset comes along and check this flag just before calling Wimp_Poll - then you can kill OS_ExitAndDie or whatever it is. That is the normal way of signalling conditions to your main program from code which is not allowed to call it directly. > Can a utility (filetype ffc) be a wimp task? What's the point, if you are going to use a module? (unless you want to use the application workspace, I suppose.) Stewart Brodie University of Southampton
bdb@cl.cam.ac.uk (Brian Brunswick) (06/27/91)
>task so that it does not need a whole page to itself. Can a utility >(filetype FFC) be a wimp task? I've tried to do this, and it doesn't really work. The problem is that a utility has state left on the supevisor stack I believe, and this gets trashed whenever a new application starts up. So apart from any possible problems beacuse the Currently Active Object mechanism doesn't expect a utility, whenever another application is started while the utility is live, memory gets lost and a wild jump prepares... I eventually reached a partial solution by having my utility set up a os variable, and doing a wimp=starttask (which was the object of my exercise) on that variable from an Obey file. But this is no good for your purposes :-( Brian.Brunswick@uk.ac.cam.cl Disclaimer. Short sig rules!
hughesmp@vax1.tcd.ie (06/28/91)
In article <8315@ecs.soton.ac.uk>, snb90@uk.ac.soton.ecs (Stewart Brodie) writes: > In <1991Jun27.052256.1@vax1.tcd.ie> hughesmp@vax1.tcd.ie writes: > >>I am writing a module wimp task that must not survive reset > Why don't you have a flag in your workspace which gets set when a > Service_Reset comes along and check this flag just before calling > Wimp_Poll Because I would prefer if it would die on reset - I don't want it to have to wait to be re-initialised as a wimp task before it kills itself. >> Can a utility (filetype ffc) be a wimp task? > What's the point, if you are going to use a module? (unless you want to > use the application workspace, I suppose.) Because a utility is a transient program, that can take up less than a page, is unlinked on reset, and can terminate at any old point just by doing a MOV15,14 - no need to kill itself. Basically, I have a very small program that needs to be a wimp task, must _die_ on reset, and I don't want to be a normal wimp application that takes up a whole page because it is a big waste of space. Owen Smith suggested to pmf (Ian Ashley) who suggested to me doing a CallBack on the Service_Reset, to kill the module later. I shall give this a try as it sounds feasible... Merlin. --SICK--
joe@tharr.UUCP (Joe Abley) (06/29/91)
I'm sure I've seen wimp tasks running in the RMA from Utility-type files.
The RMA is where these "transient" utilities are installed, after all,
not the supervisor stack, isn't it?
They come up under "Modules" in the Task Manager window, and disappear
(naturally) on a reset.
--
/---------------------------------+ * Tharr *
| joe@tharr.uucp | Free Public Access UNIX in the UK
\---------------------------------+ call +44 234 841503