Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!mcsun!ukc!stl!robobar!ronald From: ronald@robobar.co.uk (Ronald S H Khoo) Newsgroups: comp.unix.xenix.sco Subject: Re: Bugs Message-ID: <1991Apr30.103044.10663@robobar.co.uk> Date: 30 Apr 91 10:30:44 GMT References: <1991Apr29.172335.573@sbcs.sunysb.edu> Organization: Robobar Ltd., Perivale, Middx., ENGLAND. Lines: 38 jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: > - 'badtrk' says: "couldn't malloc" Fixed in the xnx155b support level supplement. > - Using '-Ox' in cc is very very broken. Heh. Does it matter ? -Ox is "unsafe" anyway. It implies -Oa which will break perfectly good C code even if it worked perfectly. > - Reliable signals were added, but nothing generates SIGIO (there's no > ASYNC flag for fcntl or open). Well, that's two separate issues. At least, with the advent of reliable signals, the race condition in sleep(3) doesn't exist anymore. SIGIO's a nasty kluge anyway. Reliable signals, on the other hand, are rather vital -- I'm very grateful that they were added. > Since they don't, I have to use forks (big 'threads') and message passing if > I want to wait for a clock tick, a keypress and IPC from my database server > all at the same time. And that has problems because you can't search > through messages (to pick the one you want) and because message queues and > buffers easily overflow. Why not use pipes instead? Then you can select() on which pipe to read from (but you need the kernel fix in either xnx141 or xnx155b to make this work) -- yes, the Xenix select() is a real BSD select. > - There seems to be shared libraries (/bin/shlib) but no documentation for > it. To generate shared library applications, you'll need a Development System that can generate them. This means that you'll have to buy a COFF development system, like the SCO UNIX one. (Or use the reverse engineering kit that PGD posted a while back, maybe?). -- Ronald Khoo +44 81 991 1142 (O) +44 71 229 7741 (H)