Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re:  Request for technical assistance in CMU/Tek programming
From: <miller@tgv.com>
Date: Thu, 19 Nov 1992 17:32:01 -0800 (PST)
Reply-To: <MILLER@TGV.COM>
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>
CC: MILLER@TGV.COM, cmu-tek-tcp@cmutek.cc.cmu.edu
Mail-System-Version: <MultiNet-MM(331)+TOPSLIB(156)@TGV.COM>

>When you perform the NET$OPEN, you don't get a new name of the device.
>The only device name that you have is "IP0", which is used by all
>TCP/UDP/etc connections.

Try this:

	p1:  $ASSIGN a channel to IP0:
		the driver will clone the device and send
		you back an IP7: (for example)
	p1:  NET$OPEN a link to the network
	p1:  SYS$GETDVI to get the name of the device (IP7:)
	p1:  spawn the subprocess, p2, and pass it the name (ip7)

	p2:  Is passed the device name (IP7:)
	p2:  $ASSIGN a channel to IP7:
	p2:  NET$READ from new channel

	p1:  spawn the subprocess, p2, and pass it the name (ip7)

	p3:  Is passed the device name (IP7:)
	p3:  $ASSIGN a channel to IP7:
	p3:  NET$WRITE to new channel

>The question that I was raising was whether creating a device channel
>with some special attributes would make it sharable by other processes.

I presume the SHR bit is set in the IPDriver's DEVCHAR field.  If not,
then you could try setting it on yourself, or asking CMU to change it.
I don't see any reason why it wouldn't work.

>One possibility that I saw was creating the device channel in
>either exec or kernal access mode.  We tried this out;  it didn't work.

Nope, channels are owned by a single process.

>We tried this out.  It didn't work.  Let me give you an example that
>will explain why it cannot work.  Suppose there is a process A that
>creates 3 separate TCP conections.  I give you some quick pseudocode:
>
>  SYS$ASSIGN first link using "IP0" as device
>  NET$OPEN first link to remote node #1
>
>  SYS$ASSIGN second link using "IP0" as device
>  NET$OPEN second link to remote node #2
>

Everytime you $ASSIGN to IP0, the template device, you create a new
cloned device; IP1, IP2, IP3...

>If you having WORKING code to prove me wrong, send it to me and I
>will read it (and eat my words).  I have working code to perform
>QIO reads and writes for a passive TCP connection, an active TCP
>connection, a UDP reader task, and a UDP writer task (inspite of
>the fact that the documentation on the NET$OPEN for UDP NET$OPENs
>was incorrect).

Sorry about that.  Probably my fault.

>Test #1:
>
>Process A
>
>   SYS$ASSIGN link
>   NET$OPEN link
>   SYS$CREPRC subprocess B
>   SYS$CREPRC subprocess C
>
>Process B
>
>   NET$SEND to channel id from process A (SS$_NOPRIV error)

The channel id from process A has no meaning in process B.  The channel
ID is an index into a table of CCBs maintained on a per process basis.
The same way that File ID 5 in process A is differant from File ID 5
in process B on a Unix system (though they may point to the same
socket in the case of a fork call).

>When you disable ASTs, you stop new ASTs from arriving.  You DON'T
>suspend an AST that is currently executing.

If an AST was already executing then your code wouldn't be executing.
This is the method used to syncronize the two threads in the CMU
ACP process.

>I work with an application that involves a hundred or more processes
>that call common routines that may or may not already have
>routines in them invoke ASTs.  I have to synchonize between not only
>each of the processes for certain select portions of code that
>update data structures but I have to synchonize between a mainline
>thread and an already executing AST that might be calling the same
>routines.  I try to reuse as much code as I can without writing new
>code.

You could always have the AST insert an entry in a "work queue" that
was dispatched by the main loop of your program.

-bruce