You can of course use ACE - Adaptive Communication Environment -
http://www.cs.wustl.edu/~schmidt/ACE.html to solve
the thread incompatibility issue.
Alex
Nadav Har'El <[EMAIL PROTECTED]> wrote:
On Tue, Jan 09, 2001, Shlomi Fish wrote about "Does the other UNIXes hold Linux up?":
>...
> However, an implementation as a separate thread would still be better
> logistically. Still, the KDE developer said that it was not possible,
> because:
>...
> B. Partially, multi-threading on other UNIXes is not as solid as on Linux
> and/or it requires some tweaks at compile-time.
>
> I had a talk about it with Guy Keren, and he said that in a way, trying to
> adapt software to other UNIXes beside Linux, causes Linux to hold up and
> not gain enough momentum. If we strive only for the lowest common
> denominator, we lose all the great functionality Linux has to offer.
>
> Of course, in a way it also works in reverse, because, for example, Linux'
> support for Access Control Lists is not as mature as in other UNIXes.
>
> Do you think that trying to achieve compatibility with other flavourse of
> UNIX, prevents some improved software to be written on Linux?
This is a very old "problem" facing UNIX software developers. Over the
course of the last 15 years or more, I've had the opportunity (pleasure,
actually) of using Unix from about a dozen different vendors (Sun, DEC, SGI,
AT&T, Microsoft, Linux and more), and an even greater variety of versions.
At each phase, the most advanced features (be they job control, X-Windows,
motif, TCP/IP, shared libraries, or the other features-du-jour) where never
found in all Unix versions, or if they were found, they were found in
different quality or different flavors (see especially the SystemV/BSD
differences).
This was a real problem even for "typical" Unix programmers, because though
your department was using a VAX mainframe this year, next year they may be
using a Sun workstation, and later PCs running AT&T SystemVr3 Unix, or
whatever. Unlike Microsoft (DOS->Windos3.1->Windows 95->...) users, Unix
users were traditionally not bothered with the issue of binary compatibility:
when you got a different system you would just recompile your programs (after
a few fixes that are sometimes needed) - all your source files, and text files
continued to work as they did in the old system.
Not caring about binary compatibility made switching vendors very common in
the Unix world.
The way Unix programmers overcame this problem was to try to write programs
that work, one-way-or-the-other, on all (or most) Unix flavors, by taking
advantage of advanced features when possible, and circumventing them when
not available (when completely circumventing a feature was not possible, the
program would still run but with slightly reduced functionality). For example,
A program might have an X interface where X-Windows was available and a
textual interface for where X is not available, or it might use newer X11R4
features when available, or fall back trying to imitate these things when not
available. It might use cbrt() function to calculate a cube root is that
function is available, resorting to the general and less efficient pow()
otherwise. "autoconf"-like solutions cropped up all over the place to
help the programmer find which features were available on which system.
So if you ask me, if there are still "important" systems where Posix-threads
is not available (I don't know if there is... I don't consider supporting
aging SunOS 4 workstations as very important), then you should write the
program to work under such systems, e.g., by doing the "context switches"
yourself, manually letting each task do some work. But you can #ifdef a
different piece of code that does the same thing using threads.
You may argue that having two alternative codes #ifdef'ed is ugly, and hard
to maintain. This is true to some degree, but remember that one of them (the
non-threaded one) is only a relic to support legacy systems, and in the
future all Unix systems will support them (no Unix vendor has any reason
why they shouldn't support Posix-threads - this is a very accepted standard).
Alternatively, you may decide that the entire freecel-solving capability
will depend on threads, and where threads is not available, the solving of
the game will not be available (this is not so terrible, in my opinion,
especially if writing the non-threaded version is very difficult).
Of course, if you find that you don't need threads in your program other
than for a very small thing, you should try to avoid using them - even if
you'll have threads on any system you use. This is just like you should avoid
having a huge backend-processing program require X-Windows just to pop up
a "success" message at the end. Using another library adds complexity,
and dependence on that library, that should be avoided if you don't really
need that library.
--
Nadav Har'El | Tuesday, Jan 9 2001, 15 Tevet 5761
[EMAIL PROTECTED] |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |I had a lovely evening. Unfortunately,
http://nadav.harel.org.il |this wasn't it. - Groucho Marx
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
Alex Landsberg
[EMAIL PROTECTED]
972-9-7413725
972-54-970352
---------------------------------
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
