Monsieur Thibault,
As you seem to be the person committing things to libpthreads, the Makefile
reads at line 246:
ifeq ($(IN_GLIBC),no)
$(inst_libdir) = $(libdir)
endif
Make keeps dieing on line 247 there: it complains about an empty variable.
I am trying to build libpthreads as a part of the hurd
From: Richard Braun
To: Thomas DiModica
Cc: "debian-h...@lists.debian.org" ;
"bdefre...@debian.org"
Sent: Tuesday, July 31, 2012 4:48 PM
Subject: Re: Hurd_condition_wait in glibc libpthreads in Debian
On Tue, Jul 31, 2012 at 03:16:05PM -0700, Thomas DiModica wrote:
> A
>No, the semantics are the same. The internal implementation may slightly
>differ, I haven't looked in detail. The point is how to handle
>cancellation from a cancelled thread, not how to mark a thread as being
>cancelled. The hurd_thread_cancel function merely exists because there
>isn't any in
>No, the semantics are the same. And you're saying it yourself :
>"hurd_thread_cancel kindly informs the thread that it has been
>canceled". The description of pthread_cancel is "The pthread_cancel()
>function shall request that thread be canceled. [...] The cancellation
>processing in the target t
I was thinking about what Richard Braun said about removing hurd_thread_cancel.
Attached is an exploration into implementing PTHREAD_CANCEL_HURD as a
cancellation state extension. It compiles, but I haven't tested if the
resulting library
still works.
A server would call pthread_hurd_server_np u
Sometimes, I ask questions early, without thinking for myself of the answers:
>> PS. In timedwait, we dequeue the thread, but the cleanup handler (which is
>> always run) ensures that the thread is dequeued also. Is this necessary, or
>> just an artifact that is due to how all of the timed functi
I don't know if anyone other than Barry has had a look at the pthreads
based hurd that I had in a BitBucket repository, but now that
Richard Braun has created a branch on the Savannah servers, I will
be removing the BitBucket repo.
The pthreads code is now in rbraun/hurd_with_pthreads.
Thank you M
I'm CCing this to bug-hurd.
So, this is the long version of what my pthreads patch to ufs does.
If anyone finds my beliefs to be in error, please speak up.
I will begin by describing how a cthread rwlock worked, in brief. Inside the
cthread rwlock, there is a condition that all waiters sleep on.
- Original Message -
From: Richard Braun
To: Thomas Thomas
Cc: bug-hurd@gnu.org
Sent: Wednesday, August 15, 2012 3:24 AM
Subject: Re: Compiling ext2fs.static with pthreads
>On Tue, May 08, 2012 at 07:16:09PM -0700, Thomas Thomas wrote:
>> So, it runs as a translator. Spews out some unexp
>How I got around this was to apply Thomas Schwinge's fix_have_kernel_resources
>branch to libpthread. Basically, the first thread structure allocated is not
>zeroed out,
>so have_kernel_resources is some random non-zero number, and thus the thread
>neither gets a wakeup port, nor does the kernel_
My understanding is that pthread_cond_wait is a cancellation point.
It achieves this by entering asynchronous cancellation mode before blocking.
I don't see, however, any code that checks for a pending cancellation when
we enter the function. As far as I can tell, the implementation is that
pthrea
The only thing that I would include is that the current pthreads
branch is best found here, thanks to Richard Braun:
http://lists.gnu.org/archive/html/bug-hurd/2012-08/msg00062.html
Thomas DiModica
12 matches
Mail list logo
