[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pexec :)



James Cox writes:
> I have been fiddling around over the past couple of days, trying to do two
> ultimately simple things.
> 
> Firstly, I thought I'd try and get around the fact that MiNT doesn't have a
> non-blocking fork

 (tho there are diffs that change this.)

>  by using Pexec's mode 104 (I think) that just runs a
> basepage concurrently where the child shares the parents memory. The basepage
> I passed was the parents... (I have this little bit of code that checks a flag
> that tells the process if it's the child or parent :)

 you can also call tfork() it does the same...

>  Everything worked really
> well, except that if the child terminates before the parent, the child enters
> EXIT state until the parent terminates...

 thats normal (its called a zombie), use wait() just like you do after a
regular fork().
> 
> Secondly, I was trying to get around the really annoying aspect of GEMDOS that
> hath plagued my life since the dawn of time - the fact that when a program is
> first executed, it is given ALL of the availalbe memory.

 Yes and i still think the kernel should at least _try_ to do everything
to make sure a well-behaved process that does its Mshrink() within the
first few (nonblocking) syscalls and first few milliseconds of its(!)
time will _not_ cause another process memory request fail just because
of a stupid race.

>...
> The only thing I can't quite understand is that whilst in the EXIT state, the
> process is not, according to TOP, using any memory (or processor time :) but
> still registers. If I try to kill it from TCSH, then it says that it couldn't
> find the process... Why doesn't MiNT dump the thing and be done with it?

 because you might be intrested in your childs exit code for example?
at least for fork (tfork is a MiNT extension) this is standard un*x
behaviour. 

>  Is
> there a way of doing what I am attempting that I am unaware of?

 no longer now i guess... :)

 oh and if you don't have a good place for the wait() call or you want
to know ASAP when your child(s) die then set up a SIGCHLD handler.
> 
> As as result of these pass few days, I would like to propose a new flag for
> Pexec that indicates that the program should be loaded into a memory block
> just big enough for the program. I understand that this would cause some
> difficulty, since the program being launched in this way would have to be able
> to detect whether or not it needs to perform a memory shrink call or not,
> otherwise it won't run very nicely without MiNT.

 hmm actually not...  Mshrink won't fail (at least shouldn't) when the
new size is == old so it could simply be left in.  only the bss size in
the header then would have to include _stksize, unless we want the stack
then be allocated thru an extra Malloc syscall...  ie a change in crt0
and fixstk would be in order.
> 
> Apologies for waffling on a bit :)

 meetoo,
	Juergen :)