🚀 go-pugleaf

In article <657916216.AA4508@flaccid> keyvan@pyra.co.uk (Keyvan Shirnia) writes:
>In article <1990Nov6.015433.10642@mathrt0.math.chalmers.se> augustss@cs.chalmers.se (Lennart Augustsson) writes:
>
>> [stuff deleted]
>
>Well, if all your processes are running on the same machine, you do not
>need to use sockets. I think a better solution would be to use pipes.
>(Although pipes are built using socketpair() system call!! ;-)
>
>So the idea is something like this: (!)
>
>When spawning its processes, the parent  can also open up pipes between
>itself and its children. Then by simply using read() and write() system calls
>you can transfer data between your processes.  If you don't want the children
>to hang around the read() system call (block for data to be written to the
>pipe) then I'm afraid you have to use signals. (ie. send a signal to the 
>child process when you know you are about to send the data to the child)
>
>Not a very pretty sight!! ;-)
Among my parallel process there is no master (there is of course a
parent, but this is forgotten after the startup phase), and I would like
to keep it that way.  As you say you could do something with pipes, but
since I absolutely don't want any processes hanging anywhere in the
normal case this would involve signals and would be messy.

>>4.3 BSD Unix contains a way to distribute file descriptors through the
>>sendmsg and recvmsg system calls, but as usual Sequent are years
>>behind when it comes to the operating system (sendmsg&recvmsg can send
>>file descriptors in the UNIX domain on vanilla 4.3 BSD, Ultrix, and
>>SunOS).
>
>Can I just say something here! You mentioned you would like to distribute
>the file descriptors between your processes. I think it is worth mentioning
>the fact that you have to send the filename to the children. It's the children's
>job to open files and get appropriate file descriptors. 
Not so!!  You don't have to distribute filenames.  One process can open
a file (or create it with socket, or any other way you can get a file
descriptor) and then send this to any other process using a UNIX domain
socket with sendmsg and having the socket in the accright field.  When
the sender closes that file descriptor (which may be dup:ed if you want
to keep the original) the receiver can use the number it got in the
accright field as a file descriptor and it will refer to whatever it refered to
in the sender.

>The child as a process has its own user space, which is totally seperate from 
>its parent. So the child is totally unaware of the fact that the parent has 
>just opened a file, and updated its user space file table. However, if the
>parent opened up the file before spawning any processes, the children will
>inherit the parents file table including the file descriptors.
Well, that's exactly the problem.

>sendmsg and recvmsg are just equivalent to write() and read() on pipes,
>respectively.
On pipes yes, but not on UNIX domain sockets.  What I had in mind using
sendmsg/recvmsg would also involve signals, but in a rather safe way.
It would work like this.  Whenever a process has opened a new file it
will (for each of its coworkers) dup it, send it with sendmsg, close it
and send a signal to the receiver.  The receiver will in the signal
routine do a recvmsg (and maybe store the descriptor in a table) and then return
from the signal routine.  Any future attemt to read can then be
done via this descriptor.

>>(I have another solution using signals in mind, but I don't like it.)
>
>You have to be very wary  when using signals. Its very easy to get mixed up
>with all the processes talking to each other using signals.
I know!

>Just for your information, this task under ATT's inter process communication 
>is very much simpler. All you need to do, is to setup a shared memory segment, 
>and lock the segment using semaphores. This way the parent has control over the
>children and can indicate when they should read data from the shared memory.
>NOTE: you would still have to use signals, if the children are unable to block
>on the semaphore lock.
The processes are already running in shared memory (with locks and all).
The problem is (as I said) that there is no master process, all proceses should
be considered equal so that any one of them can perform any of the many tasks
in that makes up my program.  This means that as soon as one of them opens a
file and gets a new descriptor all the others should be able to read/write
on that descriptor to.

>I hope this helps.
I'm not sure it does, but thanks anyway.

I have some alternative solutions, but I don't like any of them (I don't like
the sendmsg/recvmsg either, but I think it's the best so far):
1) Have a designated I/O process.  All I/O is performed by this process
and the workers have to send some kind of "requests" to it, results will
be returned by having the I/O process putting it in shared memory and
signalling via some semaphore.
2) Whenever a file is opened a table (in shared memory, btw. there already is
one since all processes share I/O buffers, buffer pointers, counters etc.) is
updated with the process id of the opener.  When someone else needs I/O on
this descriptor it will place its request somewhere in shared memory and signal
the opener.  It's signal routine will then perform the request, signal back
somehow and return.  I hate all this signalling and semaphores, it's inefficient
and error prone.

>
>Best regards,
>Keyvan
>
>P.S. If you have any more questions regarding this, please Do ask!! ;-)
>



	-- Lennart Augustsson
Email:	augustss@cs.chalmers.se