michael@stb.UUCP (Michael) (05/06/88)
In article <517@viscous> brianm@sco.COM (Brian Moffet) writes:
that he would like to see unix on amiga's, and mentions all sorts of
"good" things about unix. (Such as consistent devices (YEA!) and
"standard networking" (presumably meaning sockets.)
My rebuttal:
Unix? Isn't that the thing that limits you to 16 files per process?
In Chaos (Commodore's Home-made Amiga Operating System), there is no
limit to the number of message ports or file handles you can have
open.
In sockets, you are heavily limited to only 16 total.
In Chaos, you can have one message port to talk to everyone, simplifying
all your communications
In Sockets, you have one message port for making connections, and you must
have another port for each person you are currently talking to. (16 max).
In Chaos, you can easily wait for a message on any port, including getting
software interrupts, or even running as the task that sent you the message
(undocumented, but it's there in 1.2)
In sockets, you can only select(), and then you have to actually poll
to see which one said hi. If you poll in order (1-2-3-4-5-etc), it is
possible for a message to come in on 2 after you've check it.
In Chaos and V7-ATnT, pipes are atomic.
In sockets, pipes are completely unguaranteed for multiple writers.
Michael
p.s. "Give me a good multitasking system with decent networking, or give
me death (a model 1 in good working order)".
p.p.s. I have no complaints with sockets as a user interface to a better,
lower level raw interface. I'll use the raw, and programs that I want to
port will use sockets. (This, in fact, is my biggest complaint with sockets--
datagrams are almost impossible to rip out for non-networked machines, and
streams provide almost no added functionality over named pipes (and if that
extra functionality is used, they too become un-removable)).
--
: Michael Gersten uunet.uu.net!ucla-an.ANES\
: ihnp4!hermix!ucla-an!denwa!stb!michael
: sdcsvax!crash!gryphon!denwa!stb!michael
: "This signature is too tame; anyone got some gasoline? "dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/08/88)
:In article <517@viscous> brianm@sco.COM (Brian Moffet) writes:
:that he would like to see unix on amiga's, and mentions all sorts of
:"good" things about unix. (Such as consistent devices (YEA!) and
:"standard networking" (presumably meaning sockets.)
:
:My rebuttal:
:Unix? Isn't that the thing that limits you to 16 files per process?
...
:In sockets, you are heavily limited to only 16 total.
:In Sockets, you have one message port for making connections, and you must
:have another port for each person you are currently talking to. (16 max).
...
:In sockets, you can only select(), and then you have to actually poll
:to see which one said hi. If you poll in order (1-2-3-4-5-etc), it is
:possible for a message to come in on 2 after you've check it.
Where did this guy come from? This is total bull and everybody
knows it. I don't even know which UNIX system you are comparing. In
the system I use (BSD4.3), the PER PROCESS limit can be anything up to
256, and is usually set at 64. The select() call returns variables
telling you *exactly* which file descriptors are ready for reading,
writing, or have an exceptional condition pending, no polling involved
from the process's standpoint (though I admit there is considerable
overhead for the system setting up the sleep/wakeup). Anybody who uses
select() not only knows this, but understands the programming mechanics
of it as well...
"If you poll in order ..." . no dah, the same thing would happen
under any multiple-stream based file handled system. When you loop around
to the next select, it returns immediately with the 2 that came in after
you processed them. Atomic operations don't exist under sockets (for
STREAM sockets), at least not in terms of getting arbitrarily sized data
blocks (>1K) in one read(), but then again, since you know the block size
it's trivial to loop on it and get 'atomic' operations. There are a
thousand ways to do it.
As far as multiple writers go, it's quite simple.. you just
dup() a socket descriptor, fork (or fork/exec), and whalla, you have
multiple writers. You seem to have glossed over the reasons WHY UNIX does
things the way it does. Does the word "firewalls" mean anything? How
about "Network Compatible Communications Standard"??? I don't know about
you, but I like being able to ftp some far away ARPA node from any machine
on campus.... the networking system may transparently route it through a
dozen machines or more, but it works quite efficiently.
-Mattford@elgar.UUCP (Ford Prefect ) (05/09/88)
Uh-oh, another one of those articles where I won't be able to sleep with the thought that someone might read that article and actually *believe* some of it... In article <10227@stb.UUCP> michael@stb.UUCP (Michael) writes: >"standard networking" (presumably meaning sockets.) Not necessarily sockets. AT&T has a completely different IPC/ networking methodology. I don't know why, since BSD networking is one of the few BSD enhancements that was neither a hack nor a kludge, but a very well-designed system. >My rebuttal: >Unix? Isn't that the thing that limits you to 16 files per process? In the olden days many years ago, Unix systems were typically configured with a maximum of 20 simultaneously open files per process. Nowadays it's a tunable kernel parameter, with a typical value of 60 or 80. I never found 20 to be a limitation anyway, although it was a bit silly that the older Sun servers could only serve 19 workstations at a time. >In Chaos (Commodore's Home-made Amiga Operating System), there is no >limit to the number of message ports or file handles you can have >open. >In sockets, you are heavily limited to only 16 total. (The limit is more like 100, see above.) If you can think of an application that can use that many separate connections, I'll be surprised. >In Chaos, you can have one message port to talk to everyone, simplifying >all your communications If you find this simpler, you can do it with sockets too. >In Sockets, you have one message port for making connections, and you must >have another port for each person you are currently talking to. (16 max). This is only if you choose to make a connection, something which "chaos" can not even do. And again, your number 16 seems to have come out of thin air. >In Chaos, you can easily wait for a message on any port, including getting >software interrupts, or even running as the task that sent you the message >(undocumented, but it's there in 1.2) Same with sockets, except the last bit, which is not applicable to the socket abstraction anyway, since it is much more general (i.e., the "other end" can be on a different machine on a different network with a different type of CPU). And with Unix you can wait for a message on things other than an ipc port (like a serial port). >In sockets, you can only select(), and then you have to actually poll >to see which one said hi. If you poll in order (1-2-3-4-5-etc), it is >possible for a message to come in on 2 after you've check it. This is not true. All normal I/O operations are applicable to sockets, and the select function returns a list of descriptors which are ready. The select() process is reliable in that you will never sit waiting for a message when you already have one ready. And it's actually "chaos" where you have to poll, or be limited to 16 signal bits for message ports. If you use software interrupts, you still have to signal your process, and either do the equivalent of polling or again devote a signal to each type of event you want to see. But I still think that most programs are only interested in one or two types of messages and will not be wanting to select lots of message ports. If it's properly designed, it can have just one main input stream and encode the message type and reply-address in the message. This works with Exec messages or BSD sockets. >In Chaos and V7-ATnT, pipes are atomic. Also not true. "Chaos" does not have pipes. Unix pipes are not atomic; you can read any or all of the bytes that have been queued in one read() call. A pipe device driver can be (and has been) written for AmigaDos, and whether it is "atomic" is up to the implementor. The same is true of Unix. >In sockets, pipes are completely unguaranteed for multiple writers. Sockets are not necessarily pipes. The pipe() call on BSD returns two connected sockets which act very much like the original pipes of Unix. But you can create sockets of your own using IP or UDP protocol and connect them. Then you have guarranteed delivery (IP) or atomic datagrams (UDP) or both if you layer some handshaking on UDP. You can choose between "connection-oriented" or "connectionless" communication and still talk to a port on another machine. Anyway, I agree that the Amiga Exec has a very powerful and flexible low-level message-passing mechanism. But it is very specialized and is optimized for a very different purpose than Unix IPC. I think that behind all stb!michael's handwaving I can see his real objections, which boil down to the standard "Unix vs. Exec / abstract vs. concrete / portable vs. programming-on-the-metal" debate which I don't want to start up again. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads
hutch@net1.ucsd.edu (Jim Hutchison) (05/09/88)
In article <10227@stb.UUCP> michael@stb.UUCP (Michael) writes: >Unix? Isn't that the thing that limits you to 16 files per process? Actually the limitation is related to the maximum number of open files a process gets (since it is done using file descriptors so you can do nice generic read/write/select on them if you wan to). This sun is very friendly and will happily let me have 30 open files. It's pretty much a configuration issue. [...] >In Chaos, you can easily wait for a message on any port, including getting >software interrupts, or even running as the task that sent you the message >(undocumented, but it's there in 1.2) > >In sockets, you can only select(), and then you have to actually poll >to see which one said hi. If you poll in order (1-2-3-4-5-etc), it is >possible for a message to come in on 2 after you've check it. Not actually, in actuality select() returns a bitmask of "ready" file descriptors. Note: with UDP (and perhaps RDP) you only need to have one port open, check out the mazewars game. Admittedly the guy(s) on the server get(s) a decided advantage when the net load goes up, such is life. >In sockets, pipes are completely unguaranteed for multiple writers. I'm confused as to what you are refering to here. >p.s. "Give me a good multitasking system with decent networking, or give >me death (a model 1 in good working order)". Give me an out-of-band message, and I'll stop taking singing lessons. :-) Jim Hutchison UUCP: {dcdwest,ucbvax}!cs!net1!hutch ARPA: Hutch@net1.ucsd.edu Disclaimer: I represent my own opinions.
david@ms.uky.edu (David Herron -- One of the vertebrae) (05/09/88)
In article <10227@stb.UUCP> michael@stb.UUCP (Michael) writes: >In article <517@viscous> brianm@sco.COM (Brian Moffet) writes: >that he would like to see unix on amiga's, and mentions all sorts of >"good" things about unix. (Such as consistent devices (YEA!) and >"standard networking" (presumably meaning sockets.) > >My rebuttal: >Unix? Isn't that the thing that limits you to 16 files per process? um, for many many versions of Unix NFILE is 20. My UnixPC has it set to 80 (I didn't know that!) and 4.3BSD has it set to 64 (I think). Maybe you're confusing it with TOPS-10 which did limit you to 16 open files? >In Chaos (Commodore's Home-made Amiga Operating System), there is no >limit to the number of message ports or file handles you can have >open. >In sockets, you are heavily limited to only 16 total. How does the OS keep track of open files internally? In Unix, the problem is that they don't have good facilities for doing dynamic memory allocation of kernal data structures. This causes the table of open files to be a fixed array (as I recall, my memory might be flaky this morning) ... If Unix were able to malloc() as it wanted then it would be able to have as many open files as it wanted, and would also be able to do a lot other things more dynamically. I suppose though that this would have an impact on performance because of the more complicated memory allocator. And if its a feature that's rarely used (at least in the minds of Unix system developors) then they have little justification to do it. >In Chaos, you can have one message port to talk to everyone, simplifying >all your communications > >In Sockets, you have one message port for making connections, and you must >have another port for each person you are currently talking to. (16 max). Actually ... you have one port in the system per application/protocol. You can have many protocols served by one process if you like. In fact, on 4.3BSD there's this guy called "inetd". His job is to keep a socket open for a bunch of the standard protocols and do appropriate things when connections are made to the socket. Some of the protocols it does internally, ping for instance. Some of the protocols it does externally by calling an external process. >In Chaos, you can easily wait for a message on any port, including getting >software interrupts, or even running as the task that sent you the message >(undocumented, but it's there in 1.2) Take a look at select(). You tell it a mask of file id's you want to wait on and when there's i/o available you're woken up and told which ones have i/o available. >In sockets, you can only select(), and then you have to actually poll >to see which one said hi. If you poll in order (1-2-3-4-5-etc), it is >possible for a message to come in on 2 after you've check it. poll? no, you're given a mask back that says which one has i/o. >In Chaos and V7-ATnT, pipes are atomic. > >In sockets, pipes are completely unguaranteed for multiple writers. > > Michael >p.s. "Give me a good multitasking system with decent networking, or give >me death (a model 1 in good working order)". >p.p.s. I have no complaints with sockets as a user interface to a better, >lower level raw interface. I'll use the raw, and programs that I want to >port will use sockets. (This, in fact, is my biggest complaint with sockets-- >datagrams are almost impossible to rip out for non-networked machines, and >streams provide almost no added functionality over named pipes (and if that >extra functionality is used, they too become un-removable)). The whole field of interprocess communications and intermachine communications is still very new and chaotic. At least sockets let you talk to machines far away which meegar DOS stuff only lets you talk to processes inside your own mahcine. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- Windowing... The Amiga has windowing. The Mac has windowing (echoes of <---- Jonathan Livingston Seagull: "Just flying? A mosquito can do that much!").
brianm@sco.COM (Brian Moffet) (05/10/88)
I read with interest the article comparing CHAOS and Unix
OS's. CHAOS sounds really nice, but I don't have access
to it at all. I read an article somewhere about how nice
it would have been but too bad Amiga-DOS is here.
(for you Commodore people out there, Amiga Dos is better than
DOS as far as I am concerned.)
However, the ability to handle fork() and a common set of
InterProcess Communications between child and parent
process would help greatly. Most times, vfork() could be used,
yes. However, there are times when one must use some
other tactics. system() is out because I personally don't
want the overhead of the shell. For example:
a program which is doing some graphics which involves
asking the user for a mathematical equation, like
sin(x*y) and then plots it.
An easy way to handle this is to have your parent program
write and compile a secondary program in the back ground while
asking the user for parameters. Once the secondary program
is compiled (found out by wait()), do a fork and dup() to
force the child process to talk via a pipe to the parent
process. The parent can then give the child a set of
paramters to the equation, and the child responds with the
answer. Very simple, but with a lot of overhead.
However, this method has less overhead than continuously running
a program everytime you want an answer, which is the only
way I could figure out how to do this under the ami. I
have not been able to figure out Messages quite yet.
Oh well, sorry for rambling, I thought I would give an example
of what I have done under Unix but not been able to do under
the amiga.
However, the amiga does handle ports of single task programs
fairly well.
--
Brian Moffet brianm@sco.com {uunet,decvax!microsof}!sco!brianm
The opinions expressed are not quite clear and have no relation to my employer.
'Evil Geniuses for a Better Tommorrow!'elg@killer.UUCP (Eric Green) (05/13/88)
in article <538@viscous>, brianm@sco.COM (Brian Moffet) says: > However, the ability to handle fork() and a common set of > InterProcess Communications between child and parent > process would help greatly. Done. There is a "spawn" command in AmigaDos, which can spawn an independent process (I don't have my manuals here at home, so I can't tell you the exact format -- it's part of the grody BCPL crud, unless you do a LoadSeg and set up a lightweight task at the Exec level, instead). Before you spawn, do a CreatePort("math.myport",0); Your brand new task then does a FindPort("math.myport"); and then sits in a loop, the first instruction of which is a WaitPort(portpointer) which puts the process to sleep until there's a message coming in. Have yourself two kinds of messages: a transaction message, and a cleanup message. The transaction message basically has a flag saying "do it!" and a bundle of parameters. Your spawned task does a GetMsg, does its duty, then does a ReplyMsg with the answer. When finished, just send a quit, wait for the reply, unallocate all memory and signals associated with the port, and go on to whatever. (NOTE AGAIN: I DO NOT HAVE MY MANUALS WITH ME. THE ABOVE IS A SIMPLIFICATION OFF THE TOP OF MY HEAD, BASED UPON A WHOLE TWO WEEKS OF AMIGA PROGRAMMING EXPERIENCE). > An easy way to handle this is to have your parent program > write and compile a secondary program in the back ground while > asking the user for parameters. Once the secondary program > is compiled (found out by wait()), do a fork and dup() to > force the child process to talk via a pipe to the parent > process. The parent can then give the child a set of > paramters to the equation, and the child responds with the > answer. Very simple, but with a lot of overhead. Functionally equivalent to the Amiga stuff mentioned above, except it may take some AmigaDOS munging to figure a way of finding when the compiler is finished doing it's exec()'ed chores. Maybe something to do with write locks and not being able to read a file that has a write lock upon it? Keep trying to get a read lock until you can do it? ARGH! BCPL! BPTR'S! KILLKILLKILL! > Oh well, sorry for rambling, I thought I would give an example > of what I have done under Unix but not been able to do under > the amiga. Oh well. Keep on trying. It takes awhile. One thing I'd suggest is reading the appropriate sections of the documentation thoroughly, while referencing a third-party manual and the "include" files and the autodocs. The Amiga is an amazingly open-ended machine -- it's possible to do almost anything, with a little effort and a decent understanding of what's going on. -- Eric Lee Green {cuae2,ihnp4}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 "Is a dream a lie that don't come true, or is it something worse?"