Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!sli!news From: rdh@sli.com (Robert D. Houk) Newsgroups: comp.realtime Subject: Re: real time operating systems for 68xxx Message-ID: Date: 15 Jul 90 20:34:45 GMT References: <8abRihm00WB9EVo18y@andrew.cmu.edu> Sender: news@sli.com (news) Reply-To: rdh@sli.com (or uunet!sli!rdh) Distribution: comp Organization: Software Leverage, Inc. Arlington, Ma Lines: 60 In-reply-to: cb1p+@andrew.cmu.edu's message of 13 Jul 90 14:33:17 GMT In article <8abRihm00WB9EVo18y@andrew.cmu.edu> cb1p+@andrew.cmu.edu (Chris Beasley) writes: 2) IO system: The IO system is single threaded and somewhat buggy. The shell interface is sonewhat inconsistent. The whole system is supposed to be multitasking and has some limited support for multiprocessing It is multi-tasking. It is very-limited ("roll-your-own") multiprocessing, offering a few low-level primitives to allow you to mix'n'match your par- ticular multi-processing (symmetric? master/slave? vector/etc/processors?) environment. but the IO system is single threaded and this has caused us no end of ?huh? While there is a limit on the number of "open fd"s, there is abso- lutely nothing in VxWorks that prevents one task from doing I/O to a (e.g.,) socket while another task is simultaneously (and non-interferingly, so to speak) doing I/O to another (e.g.,) socket, local SCSI disk, pipe, or whatever. headaches, aside from the fact that it renders the system effectively single user. This is a pain during the development cycle. The shell It *IS* a single user system. Multi-tasking, but single user. And yes, it is non-protective multi-tasking, any task can freely hang the entire sys- tem by doing something stupid or wrong (e.g., taking a system semaphore and not releasing it (such as splSemId - would hang the TCP sub-system), writing all over [another task's] memory, executing a HALT instruction, etc.). also uses a non reentrant parser so it's not really going to be easy to make a multi threaded shell. STDIN and OUT are global so the IO system can only point one place at one time. Since it is a single user system, with only one "console" terminal, this makes some sense (after all, would you want every process (e.g., "ls") you spawn on your Sun to go to the controlling terminal, or to somewhere else?). However, if for some reason you want a particular task's STDIN, STDOUT, and/or STDERR to go somewhere else (e.g., local SCSI disk file, host disk file, pipe (other task), etc.) then the facility exists to redirect locally (per-task/process) each separately [see ioGlobalStdGet() and ioGlobalStdSet(), compare to ioTaskStdGet() and ioTaskStdSet()]. By default, all tasks simply use the globally-available "console" terminal as STDxxx. Granted, if you want a multi-user general-purpose Unix timesharing system with "real-time" capability, then VxWorks is not what you want. Bear in mind that the VxWorks Shell/etc developement environment wasn't meant to be a "production" environment [at least I don't think it was, I don't work for Wind River so I obviously cannot speak for them, nor read their minds (much as I would like to), these are my opinions/observations solely], it was a developement/debugging environment to allow you to develope appli- cation(s) code to be "embedded" in a box somewhere, probably without a terminal of any type available, and certainly no humans "logging into" the system (VxWorks) shell...this is *not* to say that a lot of people haven't discovered nifty applications that depend on many of the supposedly-develop- ment-environment's features (e.g., ethernet TCP, NFS) and incorporated them into applications... My $.17 anyways. -RDH