pthread_cancel()

[Pattara Kiatisevi]

Hi,

You mean RTEMS is implemented according to POSIX but they work not in the
same way? I'm not sure I understand all what you said. It is a bit
complex.

Anyway, I read from O'Rielly Pthread Programming book and tried to make it
work with RTEMS but not successful. Every methods mentioned in the book
work on Linux but not RTEMS so how exactly to use pthread_cancel() in
RTEMS? :) Attached is my test program that works fine on Linux and
utilized both DEFERRED and ASYNCHRONOUS method.

Regards,
Pattara


On Sat, 9 Mar 2002, Joel Sherrill wrote:

> I have been thinking more and it really isn't as bad as I
> made it out to be.
>
> Joel Sherrill wrote:
> >
> > Pattara Kiatisevi wrote:
> > >
> > > Hi,
> > >
> > > Is pthread_cancel working fine with RTEMS? It doesn't seem to cancel :)
> > > I also can't find it here:
> > > http://www.oarcorp.com/rtemsdoc-4.5.1-pre3/rtemsdoc/html/posix_users/posix_users00326.html
> >
> > It is there but my reading is that it doesn't work like the Linux man
> > page.
>
> There is a man page although it is basically a shell.  POSIX called this
> Thread Cancellation and made it a separate chapter.  This is why the
> manual has an index. :)
>
> http://www.oarcorp.com/rtemsdoc-4.5.1-pre3/rtemsdoc/html/posix_users/posix_users00362.html
>
> > And the Linux man page does not look anything like the functionality
> > that
> > was in the draft spec this was originally implemented against.  Based
> > upon
> > the Linux man page, I would tend to treat this as a special test in
> > the calls listed on the Linux man page.
>
> And I still tend to think that's the right way to go.  And I think
> the RTEMS implementation is mostly there.
>
> > I am sorry to say this but the semantics of the RTEMS implementation
> > do not appear to be what any modern program using them would expect.
> >
> > This raises the question.. how critical are they to the app you are
> > porting?  If they are important, would you be willing (with advice/help)
> > to fix the implementation?
>
> I will make you an offer.  I will file a PR to track this with.  You
> start
> by writing some test programs that fully exercise the functionality of
> the cancelation manager.  These should work on Linux and I will adapt
> the
> configurery to RTEMS.  That should really be enough to identify what's
> deficient.
>
> Then identify precisely the points in the FSU and Linux pthreads
> implementation where a cancellation actually occurs inside the
> services listed.  Submit those and let me review what's broken.  I
> suspect that fixing it is not really hard and mostly a matter of
> inserting
> a cancellation test at the right point in pthread_join, sigwait, etc.
>
> And while I am fixing it, you can fill in the manager documentation
> since
> you will actually understand it then. :)
>
> As an aside, I also remember that condition variables and cancellation
> were
> very difficult to figure out how they really worked in the draft POSIX
> specification we implemented against.  And cancellation points were not
> required to make the GNU Ada run-time work which is why we initially
> implemented POSIX threads.  This is not a defense of their status, only
> some background.
>
> > > Thanks,
> > > Pattara
> > >
> > > --
> > > Please avoid sending me Word or PowerPoint attachments.
> > > See http://www.fsf.org/philosophy/no-word-attachments.html
> > > ----------------------------------------------------------------------
> > > Ott Pattara Kiatisevi                              T L W G
> > > M.Sc. INFOTECH Student, Stuttgart, Germany      http://linux.thai.net/
> > > ----------------------------------------------------------------------
> >
> > --
> > Joel Sherrill, Ph.D.             Director of Research & Development
> > joel at OARcorp.com                 On-Line Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> > Support Available                (256) 722-9985
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testthread.c
Type: text/x-csrc
Size: 2696 bytes
Desc: 
URL: <http://lists.rtems.org/pipermail/users/attachments/20020311/fcaed554/attachment.bin>