🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.transputer
Article #1702

Re: Manipulating process workspace on the Transputer

#1702
From: aghao
Date: Mon, 16 Nov 1992 11:18
45 lines
2618 bytes
Greetings.

I'm sorry I have been rather silent since I posted my original question.  I had
to leave town (:-) for a long weekend, and only returned last night.

Thanks very much for the responses.  I think my original post was slightly 
ambiguous, as I failed to explain the conditions under which I wished to access
the workspaces.  As a reminder, I said

>As part of my research, I need to be able to examine the workspace of one or 
>more Transputer processes.  Clearly, this is quite feasible, as I can get hold
>of the Wptr of a process.
>
>However, as I need to access the workspaces as separate, individual entities,
>I need to know what the boundaries are, ie where each particular process' 
>workspace starts and *ends*.  One possibility is to find out what the size
>of each workspace is, and that is what I am hoping to be able to do.

To this I would add that I need this information at run-time.  The idea is that
there are low-priority processes executing code implemented as functions
(A and B, say).  Each of these processes would have an associated workspace,
pointed to by Wptr, for local vars, params, etc.  I need to know exactly what
the size of the allocated workspace is, and I would like to design a separate
function (G, say), which, executed by a high priority process, would be able to
examine, access and manipulate the workspaces for A and B.  

I cannot rely on the chance that the 2 workspaces will be consecutively placed,
nor can I make assumptions about the workspace sizes, as that is simply 
courting disaster.  At the same time, I'm sure that information either about
the size of the workspace, or the ending address of the workspace (which amount
to the same thing) will be available somewhere.  This information will allow
me to do what I like with the workspaces of A and/or B, safe in the knowledge
that I am not tampering with the workspace of any other process(es). 

Ideally, the process G would be able to compile a table with workspace info
on all processes of interest, and would then be able to accurately access any
of them.

Thanks,

	Obi Aghanya
	Dept. of Computer Science
	University of Essex
	Colchester CO4 3SQ
	UK
Technical Details
Message-ID: <6421@sersun1.essex.ac.uk>
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!uknet!sersun1!sersun2.essex.ac.uk!aghao

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!uknet!sersun1!sersun2.essex.ac.uk!aghao
From: aghao@sersun2.essex.ac.uk
Newsgroups: comp.sys.transputer
Subject: Re: Manipulating process workspace on the Transputer
Message-ID: <6421@sersun1.essex.ac.uk>
Date: 16 Nov 92 11:18:06 GMT
Sender: news@sersun1.essex.ac.uk
Reply-To: aghao@sersun2.essex.ac.uk ()
Organization: University of Essex, Colchester, UK
Lines: 45