Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!vsi1!altos86!dtynan
From: jmberkley@watnext.waterloo.edu (J. Michael Berkley)
Newsgroups: comp.unix
Subject: Re: QNX
Message-ID: <3523@altos86.Altos.COM>
Date: 12 Jul 89 16:55:30 GMT
References: <1046@altos86.UUCP> <1096@altos86.UUCP> <1226@altos86.UUCP>
	<3482@altos86.Altos.COM> <3505@altos86.Altos.COM>
Sender: dtynan@altos86.Altos.COM
Reply-To: uunet!watnext.waterloo.edu!jmberkley
Organization: University of Waterloo, Waterloo, Ontario, Canada
Lines: 47
Approved: dtynan@zorba.Tynan.COM
In-Reply-To: bahman@nixtor's message of 10 Jul 89 21:48:38 GMT


In article <3505@altos86.Altos.COM> bahman@nixtor (Bahman Koohestani) writes:

   >QNX has a fork call and it works very efficiently.....

   Yes, QNX does have a fork call; it also works very "efficiently",
   however, it is brain damaged. Why???? Because it is nothing like
   the unix fork() call.  It does not let you pass file descriptors or
   file pointers to the son task. All it does is that it allows you to
   create a son task and then you must re-open] any files that you
   would have expected to inherit from the parent task.

Agreed!  This behaviour comes as a result of one of QNX's other weird
qualities.  QNX's filesystem is fairly fragile, in my opinion, and one
of the things that they have done to enhance stability is a mandatory
file locking concept:

	a) many people can open a file for read
	b) only ONE person can open a file for write,
	c) files cannot be opened for read and write (i.e. you can't
	open it for read if someone has it open for write and you
	can't open it for write if someone has it open for write).

So, of course the child process cannot use the same file descriptors
as the parent - some of those descriptors might be for write.

I found this behaviour very frustrating at times.  Imagine something
like news, where you couldn't unspool news if someone was reading the
active file.  QNX file locking makes this kind of administrative stuff
more difficult.  I never got used to it.

   QNX is a good system for real time (process control) applications,
   it is not as open as unix is in a lot of different ways. fork ()
   also has a lot of other side effects (depending on the version of
   QNX you are working with).  At one point, one could not create a
   background task from another background task..... SO WHAT?

Lest anyone forget, QNX is not Unix.  If you buy QNX expecting fast,
real-time Unix on your PC, you may be disappointed.  However, QNX does
have other features that make it a nice, elegant system to work with,
but it's not Unix.  I prefer Unix, but I could live with QNX if I had
to and needed real-time.

 Mike Berkley, University of Waterloo
 PAMI Lab
 jmberkley@watnext.waterloo.edu
 {utai,uunet}!watmath!watnext!jmberkley