Aha! The move to SourceForge pays off: using the web-based CVS browser, I
found that Richard has changed Player/Stage to use POSIX semaphores, and
was able to track down the problems from there. The trace I posted you
turns out to be entirely bogus, the result of a Player/Stage compatability
issue. A clean download and build of Player fixed all that, although I
still had to hack on stage/src/entity.cc to get it to handle configuration
requests.
An agro saving suggestion: whenever any of us uploads a change like this
(i.e. one requires updating and building both player and stage), we send a
message to this list. Note that I'm not pointing fingers here; I'm as
guilty as anyone on this one.
Regarding the change to POSIX semaphores (of which I heartily approve), I
have some questions.
1. There seems to be a semaphore for each player-supported entity; could
we run into a system limits problem when we have a few thousand entitied?
2. The man page for POSIX sem's says that Linux does not support
process-shared semaphores, so is it legit to put them in shared memory as
R. has done? It feels weird to have a data-structure for locking the
shared memory that is part of the shared memory (how do you lock the
lock?).
A.
On Sat, 2 Feb 2002, it was written:
> ahoward scribed:
> >
> >
> > I just updated with the latest CVS snapshot, and the Player/Stage combo is
> > broken. Stage starts, player starts, but I get a "connection refused"
> > message when I try to start any client. Can either of you suggest where I
> > should start looking (i.e. what has changed)?
> >
>
> not me.
>
> brian.
>
Andrew Howard email: ahoward@...
Department of Computer Science http: www-robotics.usc.edu/~ahoward
University of Southern California phone: 1 (213) 740 6416
Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 740 7512
<< Insert pithy saying here >>>
|