I made a new branch on my repo called easypthreads.
I also had my first run-in with not knowing crap about git.
Hopefully, all is well.
The easypthreads branch still treats pthreads as a Hurd library.
The address:https://bitbucket.org/timmytdm/pthreads-hurd.git
I also made a libpthread repo: it ha
>So far so good. I see you've renamed hurd_condition_wait in most places
>but did you move the actual definition as well? I am getting undefined
>references to hurd_cond_wait.
No, I didn't, and that is the problem. The original hurd_condition_wait
is in libthreads. That is the most natural place
From: Thomas Schwinge
Sent: Thursday, July 19, 2012 12:24 AM
Subject: Re: Concerning pthreads and such
>If you do already know a bit or two about Git and promise to be
>sufficiently careful, then I'd like to add you to the Savannah Hurd
>group, so that you can directly push to the Savannah hurd/h
_
From: Richard Braun
To: Thomas Thomas
Cc: bug-hurd@gnu.org
Sent: Wednesday, July 18, 2012 4:47 PM
Subject: Re: Concerning pthreads and such
On Tue, Jul 17, 2012 at 04:46:37PM -0400, Barry deFreese wrote:
> Have you gotten any feedback on this? Are you still working on it/testing
> it?
The only thing I've seen wrong with this branch so far:
If we fail to allocate a kernel thread while creating the thread in
pthread_create(), the wakeup port doesn't get freed.
This patch just ensures that the port isn't leaked upon failure.
TD
PthreadPatch.diff
Description: Binary data
This is mostly an informational rant: feel free to ignore most of it. I think I
have
gotten down what was going on in UFS. In Savannah task 5487, Samuel wrote:
> - Note the code in urfs/pager.c: it looks inside the rwlock in an ugly
> way. It looks like it is just trying to wait for the read lock
In function initialize_pthread in file pthread/pt-alloc.c, you need to
initialize the value of have_kernel_resources to zero if the thread
structure is not recycled. Following the logic of
__pthread_create_internal: we go from __pthread_alloc to
__pthread_thread_alloc without touching have_kernel_r
Some notes here, now that I've thought some more and done some more:
>> I caught the output of make to get the full compile command and added
>> ../libpthread/cancel-cond.o into it manually, and saved it as a shell script.
>> Barry, or someone, rewrote cancel-cond.c from cthreads into a pthreads
> Hi!
Howdy.
>On Sun, 6 May 2012 09:25:11 -0700 (PDT), Thomas Thomas
>wrote:
>> I played around and got it to compile, though how I did so is a nasty hack.
>What kind of?
I caught the output of make to get the full compile command and added
../libpthread/cancel-cond.o int
It would be. I don't write a lot of mutli-threaded code,
and I did not know that GCC supported __thread.
Well, now I know.
The implementation is much cleaner now.
Thanks,
Thomas
- Original Message -
From: Samuel Thibault
To: Thomas Thomas
Cc: "bug-hurd@gnu.org"
Sent:
I played around and got it to compile, though how I did so is a nasty hack.
Should ext2fs.static compiled with pthreads be able to run on cthreads Hurd?
It's a statically linked program that should have no external dependencies,
so it should run in any environment, right?
Thomas D
I've applied Barry's patch, and removed all cthreads references that I can find
(in the code that gets compiled). I compiled everything in the source tree,
so I clobbered the linker script version of libpthread.a. In attempting to run
ext2fs.static, I get an assertion failure in pthread (somewhere)
So, mach-defpager "wires" all of its threads. What exactly does that mean?
I think the headers are kind-of sketchy. They do say that in GNU all threads
are wired, will this apply to pthread threads, too?
Nextly, it uses cthread_data to store a pointer to a thread-specific buffer
that it uses in pa
Greetin's y'all:
So, first a question: I downloaded and am using Thibault's Hurd image. I
downloaded the build dependancies, cloned the hurd repo, compiled it, and did
"make install" (for the life of me I don't know why I thought that that was a
good idea). Everything seems to have gone well,
14 matches
Mail list logo