🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.os2
Article #160

Re: signals, threads, and memory allocation

#160
From: Robert Reichel ms2
Date: Mon, 13 Nov 1989 17:45
51 lines
3317 bytes
In article <1989Nov10.025654.3274@eddie.mit.edu> jamin@eddie.MIT.EDU (Sugih Jamin) writes:
>In article <8551@microsoft.UUCP> robertre@microsoft.UUCP (Robert Reichel ms2) writes:
>>In article <32295@ucbvax.BERKELEY.EDU> jamin@cogsci.berkeley.edu (Sugih Jamin) writes:
>>> [Why does one need to reinstate a signal handler after every use?]
>>To control reentrancy in your signal handler.
>
>This point has been well discussed by others.  I just want to mention that
>it would have been nice of OS/2 to take care of it the way BSD does, instead
>of having the programmer take care of it {him,her}self.

Fine.  I disagree.

>Ah, the manual.  It, the manual, says that I must use DosSubSet on a 
>chunk of memory allocated with DosAllocSeg or DosAllocShrSeg.  It 
>doesn't say I must not use it with DosAllocHuge.  Normally, I would 
>assume that only DosAllocSeg and DosAllocShrSeg work with DosSubSet.  
>But I have been burned once for assuming what the manual doesn't say.  
>I am referring to DosGiveSeg and DosGetSeg.  The manual for DosGetSeg 
>says that even when one already has a selector to the shared memory, 
>one still has to call DosGetSeg.  But it turns out that one doesn't need to 
>call DosGetSeg if the selector one got came from DosGiveSeg.  I found
>this out from the M&T book.  

The manual is correct, so I don't see how you were "burned".  DosGiveSeg
makes a selector valid in another process's context (ie copies descriptor
information from the LDT of the process making the GiveSeg call into
the LDT of the target process).  The recipient is able to use the segment
immediately, so of course you don't need to call DosGetSeg.

DosGetSeg is a two step process.  First, you must find out the *value*
of the selector you want to get.  You must do this via shared memory
or your favorite IPC mechanism.  Once you have the value, you must call
DosGetSeg to make it valid in your context (ie copy its descriptor
information into your LDT).  Simply knowing a descriptor value won't
do a darn thing for you.  Similarly, GiveSeg is also a two step process.
First call GiveSeg to implant the descriptor information in the target
process, and *then* pass the descriptor to the target so that it knows
which one to use.  Note that GiveSeg returns the value that is to be
passed to the target.

>Besides, calling DosSubSet on memory allocated with DosAllocHuge 
>didn't return any error.

And it will work correctly in the first 64K subsegment.  If you choose
to say that this means that it will "work" for a huge segment, that's
up to you.  The code will not allocate anything from subsequent 64K
subsegments.
-- 
My opinions are my own and to not necessarily reflect those of Microsoft
Corporation.
Robert Reichel		 {decvax,uunet,uw-beaver}!microsoft!robertre
Technical Details
Message-ID: <9005@microsoft.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uunet!microsoft!robertre
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <1989Nov10.025654.3274@eddie.mit.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uunet!microsoft!robertre
From: robertre@microsoft.UUCP (Robert Reichel ms2)
Newsgroups: comp.os.os2
Subject: Re: signals, threads, and memory allocation
Message-ID: <9005@microsoft.UUCP>
Date: 13 Nov 89 17:45:57 GMT
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <1989Nov10.025654.3274@eddie.mit.edu>
Reply-To: robertre@microsoft.UUCP (Robert Reichel ms2)
Organization: Microsoft Corp.
Lines: 51