[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Feb 17 23:04:29 2001 
Subject:Re: sys_lock_system 
From:Aaron Sloman See text for reply address 
Volume-ID:1010217.01 

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Stephen Isard <S.IsardDeleteThis@ed.ac.uk> writes:

> Date: Fri, 16 Feb 2001 15:51:15 +0000
> Organization: HCRC or CCS, University of Edinburgh
>
> I'm having trouble with the function sys_lock_system.

What exactly are you trying to achieve? Are you wanting to set up
a saved image that includes some pre-compiled code so that you can
repeatedly start it up without recompiling?

In that case, I suspect that mkimage may be what you want.

I have often copied the code in files in $popcom that make use of it.

E.g. To create the standard startup.psv used by the pop11 command, look
at $usepop/pop/com/mkstartup, which is a shell script containing just
this, which compiles lib startup (because of the last line):

$popsys/basepop11 %nort %noinit \
    $popliblib/mkimage.p \
    -nodebug -nonwriteable -install $popsavelib/startup.psv \
    startup

The last line could have been

    startup.p

or
    $usepop/pop/lib/lib/startup.p

If you wanted to include rc_graphic and objectclass (as we do here),
you could change that to

$popsys/basepop11 %nort %noinit \
    $popliblib/mkimage.p \
    -nodebug -nonwriteable -install $popsavelib/startup.psv \
    startup \
    rc_graphic \
    objectclass

You can also list extra pop11 files that are in your current directory,
or in one of the directories in popuseslist

See HELP MKIMAGE

Notice the two flags

    %nort
        i.e. do not perform any run-time actions before attempting
        to set up the save image. The reasons for this are explained
        in REF system, in section 6 on runtime actions.

    %noinit
        i.e. do not compile the user's init.p file etc.

If you were not trying to create a saved image, but merely wanted to
"lock" the system so as to reduce garbage collections after compiling a
lot of stuff, it may be that you can use sys_lock_heap() instead.

But note that if you are using X to create various windows or even if
you are using Xved, do not repeatedly call sys_lock_heap and
sys_unlock_heap, for there seems to be bug in their interaction, which
I suspect has to do with the problems of providng "holes" in the heap
for non-relocatable external structures used for X. Maybe this is
equally applicable to other external structures.

> I get an error
> message
>
> ;;; MISHAP - sys_lock_system: CALLS OF writeable HAVE BEEN IGNORED
> (pop_record
> ;;;     _writeable not set true)
> ;;; DOING    :  pop_setpop_compiler
>
> no matter what I do.  In particular, if I start up poplog 15.53,

How did you start it up? Did you include %nort and %noinit ?

If you start pop11 up, with %nort, then compile things, then
call sys_locak_heap, then want to start running programs
I think you will have to do something like

    applist(pop_runtime_actions, apply);

though I have never done this and I am not sure.

> set
> true->pop_record_writeable and then call the function, I get the error
> message.  I've tried it both under solaris on a Sparc Ultra and RedHat
> 6.0 on a pc.  These systems work fine in all other respects that I am
> aware of, so perhaps I am just doing something silly, but  HELP *
> SYS_LOCK_SYSTEM

which takes you into the middle of REF SYSTEM. You may need to read
the whole of that file to work out what is going on.

> doesn't mention anything other than the
> pop_record_writeable variable as possible reason for the function to
> fail.

>
> p.s. Apologies if this has been dealt with before.  I did try to search
> the popforum archives at http://www.poplog.org/search/, but was told
>
>             Welcome to the Bel EPA HTTPD server admin section
>                     Bel EPA Secure Server Administration
>     The server has been explicitly prohibited from making this resource
>                                  available.

It did not do that to me, but it did not appear to have any information
on sys_lock_system either!

> That "welcome" is a nice touch.  What is the server there for if it is
> explicitly prohibited from giving out information?

Must have been a temporary problem?

Aaron
===
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk   (ReadATas@please !)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html