TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: Peter Fitzsimmons
from: Ian Timms
date: 1995-04-03 01:28:00
subject: RXASYNC - Serial I/O

On the 03-29-95, Peter Fitzsimmons was chatting with Ian Timms:

[deletia]
PF>If it is not a child,  you can't pass an opened handle period.

At least we're agreed on that point.

PF>The "OPEN_SHARE_*" constants _only_ affect DosOpen().

What other kind of 'open' is there? Your statement implies that
another type exists, what is it?  And don't say fopen()/open() 
as these call DosOpen() anyway.

PF> IT> If the process is really a child then this would be true, but it
PF> IT> appears to me that MAXIMUS does not start child processes but new
PF> IT> processes in child sessions.
PF>
PF>This is not the case; 

Good to hear. I didn't think it really would be.

PF>anyway,  it is also possible to 
PF>start "child sessions",  that CAN inhereit handles (as long 
PF>as they are real OS/2 sessions).
PF>
PF>Note that cmd.exe may start a session on a program's (such 
PF>as maximus) behalf if required (for example,  the "child" 
PF>is a DOS program).
PF>
PF> IT> A child process inherits file handles obtained by its parent process,
PF> IT> along with all sharing and access restrictions specified when the
PF> IT> parent opened them.
PF>
PF>Correct;  so what is important is the "OPEN_ACCESS_*" 
PF>flags,  not the "OPEN_SHARE_*" flags.

Sharing restrictions ALSO apply, sharing is the inter-session control,
access is for within the session as I understand it.

PF> IT> To start processes of a different type you'd use DosStartSession,
PF>
PF>or exec cmd.exe...

In doing so cmd.exe would be starting a seperate session for the
program thus invoked, as you indicate above.

PF> IT> processes started using DosStartSession ARE NOT child processes
PF>
PF>This is not true;  they can be children,  if STARTDATA is setup correctly.  
PF>They CAN inherent open file handles.  

This is NOT what the OS/2 documentation states under DosOpen() considerations,
and my posting on this was taken explicitly from that documentation.  I'll take
the manuals word on this subject, upto a point. 

 Quotes from DosStartSession:

When you specify a value of 1 for Related, DosStartSession establishes a
parent session/child session relationship. A parent process/child process
relationship IS NOT established.

The InheritOpt field may be used for independent or related DosStartSession
functions. Therefore, a DosStartSession function with the InheritOpt field
equal to one is equivalent to DosExecPgm, except that the new program does
not inherit the priority of the parent process, or the keyboard and video
characteristics associated with the parent session. Also, a parent process/
child process relationship IS NOT established.

 End Quote:

It appears that if what you say is true then the DosOpen() documentation
is not comprehensive enough to cover the situation where this DosExecPgm
equivalence occurs and thus permits file handles to be inherited across
a session boundary.

A to confirm this I just came across the piece under 'Starting a Session'
and at the bottom it nicely states:

 Quote:

If the nheritOpt field in the STARTDATA data structure is set to 1, the
new session inherits the environment and OPEN FILE HANDLES of the calling
process. This applies for both unrelated and related sessions.

 End Quote:

Okay, point well taken. BUT it still ain't a child process! ;-)

PF> IT> PS. Pete, if you've got some suggestions as to how I could better
PF> IT> implement RxAsync so that it functions appropriately with Maximus
PF> IT> then I'd be glad to hear them.
PF>
PF>It sounds fine -- it is the docs that need a little 
PF>explanation,  and perhaps a sample that does not do an open.

Docs?  The documentation is in the source code, replete with usage
and parameter descriptions, isn't that enough?  Why is it that everyone
expects to be spoon-fed?  Besides which Ray Gwynn did such a good
job with SIOREF that there seems little point in repeating the
exercise, though I shall be providing an INF file with the next
release to with the basics. ;-)

PS. It was discovered that the -p parameter passing was the problem
with getting the handle.

 Cheers, Ian.

 Internet:itimms{at}ariel.ucs.unimelb.edu.au   CIS:100236,1404   [Team OS/2]
___
 * MR/2 2.1 #141 * Please Captain, Not in front of the Klingons.

--- Maximus/2 2.02
* Origin: Bunyip's Cave BBS - +61-3-859-8194 (3:633/379)
SEEN-BY: 620/243 632/103 341 348 363 633/379 635/503 640/820 690/660 711/409
SEEN-BY: 711/410 413 430 807 808 809 934 949 955 712/515 713/888 800/1
SEEN-BY: 7877/2809
@PATH: 633/379 632/348 711/409 808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.