Matthieu Nottale wrote: > Hi, > > I believe I found a bug in the Xenomai Posix skin while trying to use > boost::asio: The accept() call in asychronous mode > fails with ENOPEM instead of EAGAIN. Other than that, the call 'works' > in the sense that calling it again after a connection is established > returns a new file descriptor.
On what kind of file descriptor descriping what kind of socket are you calling accept()? So far I'm not aware of any RTDM driver providing the corresponding service - well, at least not a public one (our RT-TCP stack is yet to be released). Or is it intended to pass the call to plain Linux, switching the caller into secondary more? Jan > > I'm running xenomai rev 50ee47db78117e8711d4d2f5310dff262a425eb7 with > kernel 2.6.31 i686. > > Xenomai is built with no option (other than --enable-shared > --disable-static) to configure. > > I'm joining a simple C file to reproduce the problem. > > Its output when built 'natively', and running "nc localhost 12345" after > some time is: > > -1 11 > accept: Resource temporarily unavailable > -1 11 > accept: Resource temporarily unavailable > <...> > OK 4 > > Its output when built using the posix skin and run as root is: > -1 1 > accept: Operation not permitted > -1 1 > accept: Operation not permitted > <...> > OK 4 > > The consequence of this bug is that all applications doing asynchronous > accept() calls will fail to work, as they will incorrectly believe the > operation failed. > > > Regards, > > Matthieu > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
