At 12:04 PM 1/23/2006 +0000, Christophe Rhodes wrote:
>John Pfersich <jp1660@...> writes:
> > (Note: I don't think that the harshness of the following is
> > unwarranted. I'd certainly like to hear the rationale for using
> > futexes, given that no other *nix other than the Linux kernel has
> > them.)
>I think that the lack of constructiveness is unhelpful, and indeed
>that there are some misconceptions present in the harshness:
See replies below...
> > from the man page from futex(2):
> > Callers of this function are expected to adhere to the semantics
> > as set out in futex(4). As these semantics involve writing
> > non-portable assembly instructions, this in turn probably means
> > that most users will in fact be library authors and not general
> > application developers.
>I think that in this context SBCL is a library -- because of the
>various uses it makes of various kernel services already, I don't
>think it would be reasonable to describe it as a general application; it
>-- and I think that given the fact that SBCL _generates machine code_
It's still an application, not a library, and it seems that it's also
supposed to be cross platform. The documentation doesn't suggest a Linux slant.
>it is reasonable to accept writing non-portable assembly instructions.
>Furthermore, I believe that SBCL adheres to the semantics in futex(4).
It doesn't matter to me, it's not a library, and it's not part of the kernel.
> > I hope there was a very good payback to use the futex kludge, because
> > kludge (not a hack) is the right word for it. A shared memory system
> > sounds like it would have been a much better solution than futexes.
>The payback is "working threads", admittedly not on all the platforms
>that some users are clamouring for. However, the burden is on those
>who want things to do the work, if no source of free labour appears to
>fill their desires.
That's why I'm bitching, pissing and moaning, I will do whatever is
necessary to make this application I've inherited as cross platform equal
as I possibly can. Currently, it seems that the application is much more
lively on Linux than it is on BSD variants. I don't know this first-hand
though. We have some prospective customers that don't run Linux.
>Let me just state that in concrete terms, in case it wasn't clear: if
>a shared memory system solution comes along and is a much better
>solution, then there is no barrier towards incorporating it and it
>would be welcomed, because it is a much better solution. However, a
>non-existent shared memory system solution is not a better solution,
>because it does not exist.
Well, if it would be used, I've done it before, I can do it again, and make
it cross platform.
> > To reiterate, bare futexes are not intended as an easy to use abstrac-
> > tion for end-users. Implementors are expected to be assembly literate
> > and to have read the sources of the futex userspace library referenced
> > below.
>Which of the sbcl developers are you suggesting is not assembly
I didn't say that none of the sbcl developers are are assembly illiterate,
the quote's are from the man page of futex.
Why wasn't NPTL (native posix thread library) used instead of bare futexes?
What enterprise Linuxes have futex support in them?