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 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 :-)