From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <20200407154117.5D7D71C2@centrum.cz> <20200407171816.E0B3979D@centrum.cz> <20200408114406.6119E0D9@centrum.cz> <20200409170009.5B0DAA77@centrum.cz> <20200409201057.74CB5ED0@centrum.cz> <20200414101600.F9AA555D@centrum.cz> <20200414111059.39716137@centrum.cz> <6b8c89d1-bae0-90f5-4935-925fb0af2137@siemens.com> <50cc036c-3afd-5afd-8c94-3bdfa9d7aa6c@siemens.com> In-Reply-To: <50cc036c-3afd-5afd-8c94-3bdfa9d7aa6c@siemens.com> From: Richard Weinberger Date: Tue, 14 Apr 2020 12:56:00 +0200 Message-ID: Subject: Re: rt_task_unblock() POSIX alternative Content-Type: text/plain; charset="UTF-8" List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: =?UTF-8?Q?Petr_=C4=8Cervenka?= , Xenomai On Tue, Apr 14, 2020 at 12:44 PM Jan Kiszka wrote: > > While we are here, is there a guarantee that rt_task_unblock() can unblock > > a thread in every situation? > > I have a large Xenomai 2 application on my desk which seems to assumes that. > > IIRC, it does so for the native/alchemy API. > > > > > As far as I understand it, unblocking tasks is best effort. > > /me has pthread_mutex_lock() in mind which must not return -EINTR as > > required by POSIX. > > > > Well, when mixing APIs, you can end up in such conflicting goals, indeed. I fear more about Xenomai internals which are now based on POSIX APIs. IIRC we talked regarding this issue some time ago. Found the mail: https://www.xenomai.org/pipermail/xenomai/2019-July/041221.html -- Thanks, //richard