From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 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> <6a6aed9a-c2af-f498-4e27-bde61646a395@siemens.com> In-Reply-To: <6a6aed9a-c2af-f498-4e27-bde61646a395@siemens.com> From: Richard Weinberger Date: Tue, 14 Apr 2020 13:05:56 +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 1:02 PM Jan Kiszka wrote: > > 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... No big deal. I actually try hard to get rid of all rt_task_unblock() users in our code base. :-) -- Thanks, //richard