Xref: utzoo comp.os.os2:105 comp.realtime:290
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!ncrlnk!ncratl!scotty!bnathan
From: bnathan@scotty.Atlanta.NCR.COM (bnathan)
Newsgroups: comp.os.os2,comp.realtime
Subject: Re: OS/2, real-time, question
Keywords: OS/2, real-time, question
Message-ID: <1033@scotty.Atlanta.NCR.COM>
Date: 31 Oct 89 15:31:41 GMT
References: <34689@beta.lanl.gov> <1028@ncratl2.Atlanta.NCR.COM> <864@metaphor.Metaphor.COM>
Reply-To: r.nathan@Atlanta.NCR.COM
Distribution: usa
Organization: NCR Corporation, E&M Atlanta
Lines: 18

In article <864@metaphor.Metaphor.COM> philf@xymox.metaphor.com (Phil Fernandez) writes:
>First, there's little information about system performance, either in
>documentation or through developers' tools. 
AMEN (do it yourself.  Don't ask, I can't give it out.)
>or inter-tread communication, etc.  Also, it's difficult to understand
>"second order" effects, e.g., what's the effect on performance of
>creating one more thread.
DITTO
>Second, some key services are slow -- thread creation among them.  So,
>in applications that depend on "cheap" threads, OS/2 is perhaps not a
>great idea.
I believe threads are cheaper than UNIX processes (though I may be proved
wrong by REAL experts), and for the times when I needed a quick thread,
I just "pre-created" it and made it wait on a ram-semaphore.  Clearing
a ram semaphore gets an existing thread going real quick.

-bob (Standard disclaimer: I said "I", not "WE")
r.nathan@Atlanta.NCR.COM (404)441-8143 5555 Oakbrook #140; Norcross GA 30093