Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!jamin
From: jamin@eddie.mit.edu (Sugih Jamin)
Newsgroups: comp.os.os2
Subject: Re: signals, threads, and memory allocation
Message-ID: <1989Nov10.025654.3274@eddie.mit.edu>
Date: 10 Nov 89 02:56:54 GMT
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP>
Reply-To: jamin@eddie.MIT.EDU (Sugih Jamin)
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Lines: 75

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.

>>One doesn't have to do the same in BSD, does one?  
>Don't know.  Does it matter?

I think it was Newton who said something about standing on the shoulders of
giants.  I mentioned BSD just to point out a different implementation which
I happen to think is cleaner.  Similarly, I think Mach's way of handling 
threads is much more elegant than OS/2's.

>>Some time ago I posted a message about managing stacks for
>>threads.  Does anybody, especially people at Microsoft, know 
>>why OS/2 was not designed to manage the stacks internally?
>
>Consider that different applications may have different needs.
>It is reasonable for an application that is going to be creating
>and killing lots of threads to maintain a pool of stacks for those
>threads, so as not to endure the overhead of continually having
>to allocate and free stack space (which may fail in tight memory
>situations).  The idea was to provide flexibility to the application
>writer.

The overhead shouldn't be too bad if OS/2 manages threads' carcasses
the way UNIX does those of child processes.  A fork(2) simply breathes
new life into an abandoned cadaver, if I'm not wrong.

>>Assume that the total amount of memory I need at 
>>any one time is not more than 64K (otherwise I could use DosAllocHuge,
>>which brings me to my next question: will DosSubAlloc/DosSubFree
>>perform slower on a huge chunk of memory?)  
>
>You cannot use the suballocation calls on a huge segment.  Read
>the manual entry for DosSubSet.

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.  Besides, calling DosSubSet on memory
allocated with DosAllocHuge didn't return any error.

Now that we have mentioned the manual, allow me to ask, "Why is
Microsoft so inconsistent in making up function names?"  For dealing 
with semaphores, for example, we have DosOpenSem, DosCreateSem, etc.,
but we also have DosSemRequest, and DosSemWait.  A simple test:
is it DosSemClear or is it DosClearSem one should call to clear a
semaphore?  Then, what is the difference between DosGet and DosQuery?
Is it DosGetMachineMode or DosQueryMachineMode?  

Then there is that Hungarian notation.  It simply defeats the whole
purpose of data abstraction, doesn't it?  Even the manual itself got
confused over it.  In more than one instances, the manual errorneously
describes a variable which name begins with a 'p' as a pointer.  Not
to mention that the manual for LAN Manager doesn't follow the same
notation (nor does it use the OS/2 types).

Somebody here said that OS/2 has a lot of neat features, just that
some of them are not properly implemented.  I totally agree with
this view.  Even the manual is not properly prepared.  OS/2 in its 
current state really is half of an operating system.


sugih