From: Philippe Gerum <rpm@xenomai.org>
To: Frederik Bayart <frederik_bayart@yahoo.co.uk>,
"xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process
Date: Sat, 1 Aug 2015 10:43:42 +0200 [thread overview]
Message-ID: <55BC86BE.8090505@xenomai.org> (raw)
In-Reply-To: <694496883.6540925.1438365243369.JavaMail.yahoo@mail.yahoo.com>
On 07/31/2015 07:54 PM, Frederik Bayart wrote:
>> On Thursday, 30 July 2015, 18:10, Philippe Gerum <rpm@xenomai.org> wrote:
>> On 07/30/2015 05:08 PM, Frederik Bayart wrote:
>>>> On Thursday, 30 July 2015, 16:28, Frederik Bayart <frederik_bayart@yahoo.co.uk> wrote:
>>>>> On 07/29/2015 08:27 PM, Philippe Gerum wrote:
>>>>>>
>>>>>> Please merge the commit on top of -rc6 I mentioned this morning, which
>>>>>> fixes the spurious wake up:
>>>>>>
>>>>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=081cbb8b150f30a019245dfb0e2f0b92cc7f2dfd
>>>>>>
>>>>>
>>>>> Actually, I did not mention it, that's why we don't seem to be on the
>>>>> same page, sorry for this. We should resume the discussion from the
>>>>> situation obtained with this commit on top of -rc6.
>>>>
>>>> I have build a new rc6 kernel & libraries with the new kernel/cobalt/posix/sem.c
>>>> The rt_sem_p problem is now solved, the first process is not interrupted anymore.
>>>>
>>>> I still doesn't see the fuse file system like you do. I'm looking to other problems (select/connect/send/recv on UNIX domain sockets) so I hope that this is not the cause.
>>>>
>>>> I found already that 'select' on socket(PF_UNIX, SOCK_STREAM, 0) causes Interrupted system call (errno 4).
>>>> If I replace 'select' with '__real_select' the problem seems to be solved, and the select timeout works.
>>>> But the select doesn't seem to react on connect. I'm looking at the problem.
>>>
>>>
>>> I just notice that the flood of Interrupted system calls is only cause when build with trank. When build with alchemy, Interrupted system call just happens once.
>>
>> libtrank is just an overlay on top of libalchemy, only consisting of
>> fairly simple wrappers. I would suspect a difference in the flags passed
>> to xeno-config instead.
>
> I succeeded to start my server using alchemy directly.
>
> Via trank the program generates a flood of error:
>
> $ sudo ./ptest
>
> ptest.c:68 ERROR: select(4): Interrupted system call
> ptest.c:68 ERROR: select(4): Interrupted system call
> ptest.c:68 ERROR: select(4): Interrupted system call
> ...
>
> In attachment a test file ptest.c and makefile to reproduce the problem.
>
> My original server uses both native and posix calls, for that I used both native and posix flags.
>
> XENO_CFLAGS = $(shell $(XENOCONFIG) --posix --compat --native --cflags )
> XENO_LDFLAGS = $(shell $(XENOCONFIG) --posix --compat --native --ldflags )
>
> With alchemy directly there is no problem :
>
> XENO_CFLAGS = $(shell $(XENOCONFIG) --alchemy --cflags)
> XENO_LDFLAGS = $(shell $(XENOCONFIG) --alchemy --ldflags)
>
>
> I noticed also that for the documentation of the transition kit at the bottom http://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Using_the_Transition_Kit :
>
> If I link with xeno-config --posix --ldflags --compat, I get :
>
> cc -Wl,@/usr/lib/cobalt.wrappers -ltrank /usr/lib/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/dynlist.ld -L/usr/lib -lcobalt -lpthread -lrt -lfuse -pthread -o ptest ptest.o
> /usr/lib/libtrank.so: undefined reference to `threadobj_set_schedparam'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_create'
> /usr/lib/libtrank.so: undefined reference to `rt_task_self'
> /usr/lib/libtrank.so: undefined reference to `rt_task_wait_period'
> /usr/lib/libtrank.so: undefined reference to `xnfree'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_create'
> /usr/lib/libtrank.so: undefined reference to `rt_task_start'
> /usr/lib/libtrank.so: undefined reference to `rt_task_delete'
> /usr/lib/libtrank.so: undefined reference to `rt_task_set_affinity'
> /usr/lib/libtrank.so: undefined reference to `rt_task_suspend'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_clear'
> /usr/lib/libtrank.so: undefined reference to `threadobj_irq_prio'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_event_signal'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_task_create'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_task_set_periodic'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_pipe_create'
> /usr/lib/libtrank.so: undefined reference to `__threadobj_current'
> /usr/lib/libtrank.so: undefined reference to `__current_rt_alarm_delete'
> /usr/lib/libtrank.so: undefined reference to `xnmalloc'
> collect2: error: ld returned 1 exit status
> makefile:27: recipe for target 'ptest' failed
> make: *** [ptest] Error 1
>
> With the --native flag added, this is solved because -lalchemy -lcopperplate is then added.
The issue is not between --alchemy and --native, but with --posix being
added or not. I could not reproduce this behavior (x86, ppc or arm)
using your exact test code (I can see timeouts triggering each 5s), but
looking at it, I'm pretty sure this is due to passing regular linux fds
(from socket(AF_UNIX) to RTDM services.
When --posix is given, select(), socket() and friends will be routed to
RTDM _first_, which will check whether the corresponding channels are
connected to a real-time driver. If the fds are not managed by RTDM, the
call will be redirected to the glibc eventually. I don't explain why
your code receives EINTR from RTDM's select() yet, but this is most
likely not related to libtrank. This behavior is unexpected though, so
we have to find why Xenomai's select() behaves like this.
In the meantime, if you want to mix Xenomai/POSIX calls with regular
glibc ones when --posix is in effect, you can alternatively:
- tag all regular POSIX calls for which a Xenomai counterpart exist with
__STD(call(args))
- invoke __real_call(args)
Alternatively, you can drop --posix which will disable the POSIX
wrapping for your code, then invoke __RT(call(args)) explicitly for
Xenomai real-time services.
Philippe.
next prev parent reply other threads:[~2015-08-01 8:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 13:37 [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process Frederik Bayart
2015-07-14 9:53 ` Philippe Gerum
2015-07-15 12:45 ` Frederik Bayart
2015-07-16 15:35 ` Philippe Gerum
2015-07-28 15:19 ` Frederik Bayart
2015-07-29 10:12 ` Philippe Gerum
2015-07-29 11:48 ` Frederik Bayart
2015-07-29 12:20 ` Philippe Gerum
2015-07-29 12:28 ` Philippe Gerum
2015-07-29 12:48 ` Philippe Gerum
2015-07-29 12:56 ` Philippe Gerum
2015-07-29 15:14 ` Frederik Bayart
2015-07-29 18:27 ` Philippe Gerum
2015-07-29 18:42 ` Philippe Gerum
2015-07-30 14:28 ` Frederik Bayart
2015-07-30 15:08 ` Frederik Bayart
2015-07-30 16:10 ` Philippe Gerum
2015-07-31 17:54 ` Frederik Bayart
2015-08-01 7:59 ` Philippe Gerum
2015-08-01 8:43 ` Philippe Gerum [this message]
2015-08-03 9:59 ` Frederik Bayart
2015-07-30 15:58 ` Philippe Gerum
2015-07-30 16:36 ` Philippe Gerum
2015-07-31 16:04 ` Frederik Bayart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55BC86BE.8090505@xenomai.org \
--to=rpm@xenomai.org \
--cc=frederik_bayart@yahoo.co.uk \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.