Xref:	news-dnh.mv.net comp.os.msdos.djgpp:817
Path:	news-dnh.mv.net!mv!news.sprintlink.net!dish.news.pipex.net!pipex!swrinde!news.uh.edu!uuneo.neosoft.com!news!sandmann
From:	Charles Sandmann <sandmann AT praline DOT no DOT NeoSoft DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: V. 2.0 _go32_allocate_iret_wrapper stack not locked?
Date:	Sun, 09 Jul 1995 03:03:39 CDT
Organization:	NeoSoft Internet Services +1 713 968 5800
Lines:	21
References:	<3tmsb7$hcv AT news DOT telebyte DOT com>
Reply-To:	sandmann AT clio DOT rice DOT edu
Nntp-Posting-Host:	praline.no.neosoft.com
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

>   It seems to me that the stack created for you when you call
> _go32_allocate_iret_wrapper is never locked.  If this is so either
> there is something I don't know about or that is a bug.  Also,
> shouldn't the variable that points to the malloc()'ed stack (the one
> that get's loaded into %esp) be locked as well?  And shouldn't the
> entire wrapper code be locked as well?  Just curious, because we know
> that this code and data will be accessed from within an interrupt...

Yes, all of these things should be locked.  The problem is that when you
use these routines the C code your call code must be locked and all the data it
touches must be locked too.  This makes writing HW interrupt procedures in
C in protected mode an iffy proposition if you page at all.  So I didn't
bother.  Hey, at least the V2 versions work, unlike the V1 versions!

If you want to build bullet proof code with HW interrupt handlers and/or
RMCB's, you really need to write them in GAS, so you can put your variables
and executable code together, not have to swap stacks, and know exactly what
needs to be locked.

Or you can do what DOOM does, and just lock everything, in which case the
suggested lock calls would be useless :-)

- Raw text -