is it unix or cripplix?

A

aufreak

Registered
Dunno if it is just me, but of late I've been having a frustrating experience with OSX as a "unix" environment for development.

Yah it gives you a shell and all that, but where are the APIs? Just about every basic API seems crippled.

Ex: the pthread API is very inadequate (no rwlocks, no delaynps), time.h doesn't give access to the realtime clock using the standard clock_getxxx API calls. Phooh!

I haven't worked with BSD by itself before and am used to solaris. Is it the same case with BSD?

But I love Project Builder :) .... if only it isn't cripplix "under the hood".
 
Well, pthread_delay_np(), pthread_global_lock_np(), and their ilk are non portable by the definition, and are not part of the standard (you might know that _np stands for NonPortable). A portable way of doing _delay_np is timed wait on a condition variable, until the timeout expires (you may even want to wrap it into pthread_delay_np if you have a lot of Draft4--read DCE--source you want to reuse).

POSIX clock can be implemented using BSD gettimeofday and getrusage, throwing away information and resolution (its use is deprecated in BSD, it's there only for checkmark compatibility, since most other unices implement both gettimeofday and getrusage--in fact, I haven't found a modern one which does not)

Hope this helps
 
I guess I was too enthusiastic to expect new unices to support the open group's word on what's a unix. I obviously need to broaden my unix platform exposure. Thanks for highlighting that.
 
just to set the things right, POSIX clock API is in BSD libc; it ought to find its way into MOSX libc, as well (I was quoting parts of the BSD manpage). With, IIRC, 1 second resolution, POSIX clock is virtually useless (hence, everyone implements BSD gettimeofday and others).

The pthread _np stuff is not in BSD libc, but, it is not in POSIX either :) I'm really curious in which Solaris library did you find them, because they are available only for DCE "pthreads" (an ancient, Draft4 version of the POSIX proposal, at the time it was still 1004.d).

Sadly, a lot of POSIX is there only so that MVS and VMS could call themselves POSIX compliant; however, BSD does support most of POSIX "greatest common denominator" features, unless they are simply against the BSD point of view--that is one of the reasons why BSD is not calling itself UNIX (but is damn close :) The fact that MOSX does not implement them may be seen as a deficiency (then again, MOSX does not claim to be fully POSIX compliant, either)
 
You must log in or register to reply here.
Back
Top