From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: rt_task_unblock() POSIX alternative References: <20200407154117.5D7D71C2@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> From: Jan Kiszka Message-ID: <6a6aed9a-c2af-f498-4e27-bde61646a395@siemens.com> Date: Tue, 14 Apr 2020 13:01:58 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Weinberger Cc: =?UTF-8?Q?Petr_=c4=8cervenka?= , Xenomai On 14.04.20 12:56, Richard Weinberger wrote: > 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 Indeed, there is a todo... Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux