Re: [PATCH 08/10] hurd: Fix setting up pthreads

Applied, thanks! Sergey Bugaev, le mer. 17 mai 2023 22:14:34 +0300, a ecrit: > On x86_64, we have to pass function arguments in registers, not on the > stack. We also have to align the stack pointer in a specific way. Since > sharing the logic with i386 does not bring much benefit, split the file

[PATCH 08/10] hurd: Fix setting up pthreads

On x86_64, we have to pass function arguments in registers, not on the stack. We also have to align the stack pointer in a specific way. Since sharing the logic with i386 does not bring much benefit, split the file back into i386- and x86_64-specific versions, and fix the x86_64 version to set up t

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

Hi, Am Mittwoch, 15. Mai 2013, 00:40:55 schrieb Thomas Schwinge: > On Sun, 05 May 2013 00:33:27 +0200, Arne Babenhauserheide > wrote: > > I finally managed to write the qoth for the 3rd and 4th quarter of > > 2012, [...] > > Thanks! I just spent another hour and half on this, and it's now live

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

Hi! On Sun, 05 May 2013 00:33:27 +0200, Arne Babenhauserheide wrote: > I finally managed to write the qoth for the 3rd and 4th quarter of > 2012, [...] Thanks! I just spent another hour and half on this, and it's now live at . Grüße, Th

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

Hi, On Fri, May 10, 2013 at 09:58:28PM +0200, Arne Babenhauserheide wrote: > At the end of the last 2 quarters, Samuel Thibault pushed the [pthread > patches](http://lists.gnu.org/archive/html/bug-hurd/2012-11/msg00088.html) > from Vicente Hernando Ara, Barry de Frese, Thomas Schwinge, Richard It

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

Hi Michael, Am Freitag, 10. Mai 2013, 17:35:01 schrieb Michael Banck: > On Sun, May 05, 2013 at 12:33:27AM +0200, Arne Babenhauserheide wrote: > > A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*. > > > > At the end of the last 2 quarters, Samue

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

Hi Miguel, Am Sonntag, 5. Mai 2013, 21:42:46 schrieb Miguel Figueiredo: > Em 04-05-2013 23:33, Arne Babenhauserheide escreveu: > > A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*. > > Based on the text I would only add new installation CDs. > Looks re

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

Hi, On Sun, May 05, 2013 at 12:33:27AM +0200, Arne Babenhauserheide wrote: > A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*. > > At the end of the last 2 quarters, Samuel Thibault pushed the [pthread > patches](http://lists.gnu.org/archive/html/bug-

Re: A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

Em 04-05-2013 23:33, Arne Babenhauserheide escreveu: Hi, [...] A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*. Based on the text I would only add new installation CDs. Looks really good. [...] -- Melhores cumprimentos/Best regards, Miguel Figueiredo

A quarter of the Hurd, Q3/Q4 of 2012: *pthreads*, *hardware* and *porting*.

: *pthreads*, *hardware* and *porting*. At the end of the last 2 quarters, Samuel Thibault pushed the [pthread patches](http://lists.gnu.org/archive/html/bug-hurd/2012-11/msg00088.html) from Vincente, Barry, Thomas, Richard and Samuel and others to the different upstream packages, finally

Re: cthreads -> pthreads FOSS Factory project (was: [SCM] Web pages branch, master, updated. 306f359688afa254dc8728c73afab0fdb33d39ab)

On Tue, Mar 19, 2013 at 04:05:06PM +0100, Thomas Schwinge wrote: > I've scheduled for deletion (on Sat March 23, 11:00 EDT) the > corresponding FOSS Factory project, > . As it just had a bounty of > 40.32 EUR, but several people had been contributing to it,

Re: GCC: GNAT FOSS Factory project (was: cthreads -> pthreads FOSS Factory project)

On Tue, 2013-03-19 at 16:05 +0100, Thomas Schwinge wrote: > Hi! > > On Sat, 16 Mar 2013 18:33:28 +, Pino Toscano > wrote: > > commit 5d0f6782028c754b2c0a5721d14b8c76b47d31db > > Author: Pino Toscano > > Date: Sat Mar 16 18:59:24 2013 +0100 > > > > drop the pthread conversion project

Re: cthreads -> pthreads FOSS Factory project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/19/2013 11:05 AM, Thomas Schwinge wrote: > Hi! > > On Sat, 16 Mar 2013 18:33:28 +, Pino Toscano > wrote: >> commit 5d0f6782028c754b2c0a5721d14b8c76b47d31db Author: Pino Toscano >> Date: Sat Mar 16 18:59:24 2013 +0100 >> >> drop the pthr

cthreads -> pthreads FOSS Factory project (was: [SCM] Web pages branch, master, updated. 306f359688afa254dc8728c73afab0fdb33d39ab)

Hi! On Sat, 16 Mar 2013 18:33:28 +, Pino Toscano wrote: > commit 5d0f6782028c754b2c0a5721d14b8c76b47d31db > Author: Pino Toscano > Date: Sat Mar 16 18:59:24 2013 +0100 > > drop the pthread conversion project > > it has been done recently I've scheduled for deletion (on Sat

[task #5487] cthreads -> pthreads

Update of task #5487 (project hurd): Status:None => Done Percent Complete: 0% => 100% Open/Closed:Open => Closed _

Re: Status report on the conversion of the Hurd to pthreads

On Tue, Aug 21, 2012 at 09:44:43PM +0200, Richard Braun wrote: > Debian packages are available for testing using this repository : > deb http://ftp.sceen.net/debian-hurd experimental/ > deb-src http://ftp.sceen.net/debian-hurd experimental/ > > Upgrade glibc packages first, then the hurd and netdd

Status report on the conversion of the Hurd to pthreads

Hello, With the help of Barry deFreese and Thomas DiModica, a few machines are currently running Hurd systems with no code dependency on the previous cthreads library. Concerning upstream code, the appropriate branches can be found there : http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbr

Re: Compiling ext2fs.static with pthreads

>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_

Re: Compiling ext2fs.static with pthreads

- 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

Re: The workings of the pthreads ufs patch

On Tue, Aug 14, 2012 at 01:01:03PM -0700, Thomas DiModica wrote: > Richard, if you wish to remove this optimization for the sake of clarity, be > my guest. I was just trying to be faithful to the working of the original > code. I won't remove it for two reasons: first, it looks indeed faithful to

Re: Compiling ext2fs.static with pthreads

On Wed, Aug 15, 2012 at 11:24:20AM +0200, Richard Braun wrote: > What prevents _hurdsig_init from being called unconditionally and > earlier ? In the meantime, I merely made sigstate_is_global_rcv check that _hurd_global_sigstate isn't NULL. Now I have a subhurd completely populated

Re: Compiling ext2fs.static with pthreads

te->lock); __spin_lock (&ss->lock); } The problem is that _hurd_global_sigstate is NULL at this moment. It's part of the global signal dispositions patch, and migrating Hurd servers to pthreads means they now have to behave more POSIXely. The global signal state is normall

The workings of the pthreads ufs patch

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 sle

Pthreads Hurd branch now in Savannah

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. Than

Pthreads hurd

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

Re: Concerning pthreads and such

is the most natural place for it to be, as it is a modified form of condition_wait, and relies on the internals of a condition type. The most natural place for hurd_cond_wait to be is in pthreads, and right now the source expects pthreads to provide it. The only other solution I can thi

Re: Concerning pthreads and such

On 7/19/2012 6:55 PM, Thomas Thomas wrote: > 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

Re: Concerning pthreads and such

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

Re: Concerning pthreads and such

Hi! On Thu, 19 Jul 2012 08:24:45 +0200, I wrote: > . As this is a development branch, I do, by the way, not expect you to write a complete GNU ChangeLog snippet for this change -- let's find some useful way to abbreviate. Grüße, Thomas

Re: Concerning pthreads and such

Hi! On Thu, 19 Jul 2012 14:25:31 +0900, Samuel Thibault wrote: > Thomas Thomas, le Wed 18 Jul 2012 19:33:39 -0700, a écrit : > > should it be cloned from the GNU sources > > (git://git.sv.gnu.org/hurd/hurd.git), > > The GNU source. Agreed, and I remember you also had a patch for the additiona

Re: Concerning pthreads and such

Thomas Thomas, le Wed 18 Jul 2012 19:33:39 -0700, a écrit : > should it be cloned from the GNU sources (git://git.sv.gnu.org/hurd/hurd.git), The GNU source. Samuel

Re: Concerning pthreads and such

le is that Vicente's cancel-cond.c includes hurd/signal.h, which includes cthreads.h, which brings in a conflicting declaration for hurd_condition_wait. So, this will ease the transition from cthreads to pthreads, unless someone has an objection to me doing so. ___

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? Great stuff! Agreed. Although, if you could set up a git repository with a dedicated branch, it would make it easier for us to see and test your prog

Re: Concerning pthreads and such

debian seems to be one of the most used distributions for Hurd. > > This is a patch to hurd-20120605-2 to have it use pthreads instead of > cthreads. > It does have some issues. It still needs a libpthread directory in the hurd > source > tree (I believe that all the directo

Re: Moving ufs to pthreads

On Sun, Jun 17, 2012 at 02:58:06PM -0700, Thomas Thomas wrote: > PS - Does anyone use UFS? Probably not. -- Richard Braun

Moving ufs to pthreads

n sizes.c signals that the specific condition is valid to any threads waiting for the lock or condition. The attached file is a patch to the previous pthreads patch. It adds a condition and a lock to each resource object to allow the previous behavior without violating the integrity of any pthrea

Re: Compiling ext2fs.static with pthreads

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 c

Re: Compiling ext2fs.static with pthreads

tput 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 one. > I called it nasty because it doesn't fix the makefile, which would be t

Re: Compiling ext2fs.static with pthreads

o it manually, and saved it as a shell script. Barry, or someone, rewrote cancel-cond.c from cthreads into a pthreads one. I called it nasty because it doesn't fix the makefile, which would be the clean solution. So, it runs as a translator. Spews out some unexpected debugging info that Bar

Re: Compiling ext2fs.static with pthreads

Hi! 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? > Should ext2fs.static compiled with pthreads be able to run on cthreads Hurd? > It's a statically linked program that

Re: Compiling ext2fs.static with pthreads

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

Compiling ext2fs.static with pthreads

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)

cthreads vs. pthreads (was: GNU/Hurd in german news)

hi, On Mon, Nov 16, 2009 at 12:57:32AM +0800, Da Zheng wrote: > Samuel Thibault wrote: > > Da Zheng, le Sun 15 Nov 2009 12:05:01 +0800, a écrit : > >> I thought GNOME or KDE couldn't work because Hurd components or > >> libraries were still using cthreads inste

[task #5487] cthreads -> pthreads

Additional Item Attachment, task #5487 (project hurd): File name: patch.gz Size:123 KB ___ Reply to this item at: ___ Message pos

[task #5487] cthreads -> pthreads

Follow-up Comment #5, task #5487 (project hurd): Here is the latest patch from bddebian from goober. ___ Reply to this item at: ___ Message posté via/p

[task #5487] cthreads -> pthreads

Follow-up Comment #4, task #5487 (project hurd): Just a follow-up about the patch: - Barry's tree is in goober:/devel/bdefreese/hurd-pthread3/hurd - 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 to be avail

[task #5487] cthreads -> pthreads

Update of task #5487 (project hurd): Wiki-like text discussion box: => Would it help to have this stuff available in a CVS branch? The copyright of all involved contributors is assigned to the FSF, right? ___ Repl

[task #5487] cthreads -> pthreads

Additional Item Attachment, task #5487 (project hurd): File name: hurd_pthread_09102008.diff.gz Size:131 KB ___ Reply to this item at: ___ Message sen

[task #5487] cthreads -> pthreads

Follow-up Comment #3, task #5487 (project hurd): OK I'm attaching my latest patch. I've taken zentons work and taken it all the way. Everything compiles but there are issues. Static linking has issues. If I let the build system do it's thing, ext2fs and ext2fs --help return values however its

Re: Hurd Pthreads

Thomas Schwinge wrote: Hello! On Sat, Nov 25, 2006 at 07:51:44PM -0500, Barry deFreese wrote: OK, I have a HUGE cthreads->pthreads patch going that is going fairly well. Did you ever publish this somewhere? Did you base it on the patches that are available at &l

Re: Hurd Pthreads

Hello! On Sat, Nov 25, 2006 at 07:51:44PM -0500, Barry deFreese wrote: > OK, I have a HUGE cthreads->pthreads patch going that is going fairly > well. Did you ever publish this somewhere? Did you base it on the patches that are available at <http://savannah.gnu.org/task/?5487

[task #5487] cthreads -> pthreads

Follow-up Comment #2, task #5487 (project hurd): As far as I got it, Hurd-specific part of threads are very related with cancelation stuff. We really need hurd_condition_wait and hurd_thread_cancel or it would be possible to adapt Hurd to use pthread_thread_cancel? __

Hurd Pthreads

Heya gang, OK, I have a HUGE cthreads->pthreads patch going that is going fairly well. However, we still have an issue with hurd_condition_wait. Can that be stopped-gapped into libpthreads, or should some real glibc work be done first? In other words, am I wasting my time as alw

Re: [task #5487] cthreads -> pthreads

> > I know ;-). I would also like to know, otherwise I would have told you. > > > Does the current pthread implementation enable the use of pthreads > > in new servers-libraries-translators? In other words, can a new > > server/translator written with pthreads

Re: [task #5487] cthreads -> pthreads

- Original Message - From: "Constantine Kousoulos" <[EMAIL PROTECTED]> To: Sent: Tuesday, November 07, 2006 8:21 AM Subject: Re: [task #5487] cthreads -> pthreads Thomas Schwinge wrote: Follow-up Comment #1, task #5487 (project hurd): Attached is the work th

Re: [task #5487] cthreads -> pthreads

you. > Does the current pthread implementation enable the use of pthreads > in new servers-libraries-translators? In other words, can a new > server/translator written with pthreads coexist with the current > cthread-based servers/translators? No, translators must use the cthreads l

Re: [task #5487] cthreads -> pthreads

at *don't* work. Can someone enlighten me on that subject? Does the current pthread implementation enable the use of pthreads in new servers-libraries-translators? In other words, can a new server/translator written with pthreads coexist with the current cthread-based servers/translato

Re: [task #5487] cthreads -> pthreads

On Tue, Nov 07, 2006 at 03:21:29PM +0200, Constantine Kousoulos wrote: > What exactly does the term "mostly functional implementation" mean? Many things work, a few don't. > Has anyone considered using GNU Portable Threads > (http://www.gnu.org/software/pth/) with the Hurd? Maybe they are > eas

Re: [task #5487] cthreads -> pthreads

Constantine Kousoulos, le Tue 07 Nov 2006 15:21:29 +0200, a écrit : > Has anyone considered using GNU Portable Threads > (http://www.gnu.org/software/pth/) with the Hurd? Maybe they are > easier to become "fully functional" since they are "portable". Sorry to say that, but it's contradictory :)

Re: [task #5487] cthreads -> pthreads

g/task/?5487): "... To gain greater portability, the libraries and servers should be ported to pthreads (which we also have a mostly functional implementation for in the Hurd)." What exactly does the term "mostly functional implementation" mean? Has anyone considered using G

[task #5487] cthreads -> pthreads

Follow-up Comment #1, task #5487 (project hurd): Attached is the work that Vicente Hernando Ara has been doing years ago, see . Copyright is assigned to the FSF. This effort is unfinished. _

[task #5487] cthreads -> pthreads

URL: <http://savannah.gnu.org/task/?func=detailitem&item_id=5487> Summary: cthreads -> pthreads Project: The GNU Hurd Submitted by: tschwinge Submitted on: Monday 04/24/06 at 17:46 Category: The GNU Hurd

Re: pthreads inline functions break libgcc_s.so

At 26 Jul 2004 16:07:27 -0700, Thomas Bushnell, BSG wrote: > > Jeroen Dekkers <[EMAIL PROTECTED]> writes: > > > I think we should just remove those inline functions, because it's > > dubious whether they are a really faster and they do break > > things. What do you think? > > How on earth is it

Re: pthreads inline functions break libgcc_s.so

Jeroen Dekkers <[EMAIL PROTECTED]> writes: > I think we should just remove those inline functions, because it's > dubious whether they are a really faster and they do break > things. What do you think? How on earth is it dubious if they are really faster?

pthreads inline functions break libgcc_s.so

Michael Banck reported on IRC that the libgcc_s.so of the gcc 3.4 debian packages fail with the following error: /lib/libgcc_s.so: undefined reference to `_pthread_mutex_lock' objdump -T /lib/libgcc_s.so | grep pthread gives the following: 23:19 < azeem> D *UND*

Re: Misplaced libs for pthreads

Why are the built pthread libs floating around in cvs? Because they are not built. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Re: Misplaced libs for pthreads

On Fri, Nov 07, 2003 at 03:08:58PM -, [EMAIL PROTECTED] wrote: > Why are the built pthread libs floating around in cvs? Those .a files aren't built pthread libraries, they are linker scripts. Jeroen Dekkers ___ Bug-hurd mailing list [EMAIL PROTECT

Re: Misplaced libs for pthreads

<[EMAIL PROTECTED]> wrote: : Why are the built pthread libs floating around in cvs? They are not. If you look at libpthread.a you see that it is a link script that includes libpthread2.a. brgds, johan ___ Bug-hurd mailing list [EMAIL PROTECTED] http

Re: Misplaced libs for pthreads

Well, thanks for pointing that out. Lucas Jeroen Dekkers <[EMAIL PROTECTED]> said: > On Fri, Nov 07, 2003 at 03:08:58PM -, [EMAIL PROTECTED] wrote: > > Why are the built pthread libs floating around in cvs? > > Those .a files aren't built pthread libraries, they are linker > scripts. > > J

Misplaced libs for pthreads

Why are the built pthread libs floating around in cvs? Lucas ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Misplaced libs for pthreads

Why are the built pthread libs floating around in cvs? Lucas ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Re: Cthreads to Pthreads code.

On Thu, Oct 24, 2002 at 04:19:48AM +0200, Vicente Hernando Ara wrote: > I am changing the Hurd code from cthreads to pthreads. Goodie. > * In pfinet code appear __mutex_lock and __mutex_unlock functions, > instead mutex_lock and so. > This functions are defined in glibc. Sho

Re: Cthreads to Pthreads code.

compiling: > >exec.c:1382: initializer element is not constant > > > > however: > > pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; > > compiles ok. Why is that? > > Appearantly, PTHREAD_MUTEX_INITIALIZER is not a constant expression. > Perhaps that's

Re: Cthreads to Pthreads code.

t; pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; > compiles ok. Why is that? Appearantly, PTHREAD_MUTEX_INITIALIZER is not a constant expression. Perhaps that's a bug, I'd expect the pthreads spec to require that it's constant, but I haven't read that. Initializers for sta

Re: Cthreads to Pthreads code.

--- Vicente Hernando Ara <[EMAIL PROTECTED]> wrote: > Hi all! > > I am changing the Hurd code from cthreads to pthreads. > > There will be some patches at http://es.gnu.org/~zenton/Pthread > (there are few now ;) > > Thanks, > Vicente. (aka: zenton in

Cthreads to Pthreads code.

Hi all! I am changing the Hurd code from cthreads to pthreads. There will be some patches at http://es.gnu.org/~zenton/Pthread (there are few now ;) I wanna ask for help on the following issues: * In pfinet code appear __mutex_lock and __mutex_unlock functions, instead mutex_lock and so

Pthreads

On Tue, Jun 04, 2002 at 05:38:44PM -0700, James Morrison wrote: > > Pthreads already has recursive locks as an X/Open extension, I don't > > think such changes are needed because we will switch to pthreads > > within a few months anyhow. > > So what is in cvs

Re: pthreads

Quoting Jeroen Dekkers <[EMAIL PROTECTED]>: > Is there anyone working on pthreads? If not I want to try to finish it. > (I have holidays this week. :) I already got the code from the > sourceforgetit CVS. All I can say is that I'm not working on it at the moment (or anyth

pthreads

Is there anyone working on pthreads? If not I want to try to finish it. (I have holidays this week. :) I already got the code from the sourceforgetit CVS. I got a couple of questions: What's the status of the code? Is there anything I need to know other than what's in the TODO, NOTES

Re: Interaction of pthreads and cthreads

On Thu, Apr 26, 2001 at 04:38:22PM -0700, Jeff Bailey wrote: > On Thu, Apr 26, 2001 at 05:54:22PM -0400, Igor Khavkine wrote: > > > > I had never anticipated anyone trying to implement pthreads for the Hurd > > > in any way but by a substantial rewrite of the libc

Re: Interaction of pthreads and cthreads

On Thu, Apr 26, 2001 at 05:54:22PM -0400, Igor Khavkine wrote: > > I had never anticipated anyone trying to implement pthreads for the Hurd > > in any way but by a substantial rewrite of the libc hurd code. > > When pthreads will actually be implemented. Do you think it woul

Re: Interaction of pthreads and cthreads

> On Thu, Apr 26, 2001 at 03:57:53PM -0400, Roland McGrath wrote: > > I had never anticipated anyone trying to implement pthreads for the Hurd > > in any way but by a substantial rewrite of the libc hurd code. > > When pthreads will actually be implemented. Do you think it w

Re: Interaction of pthreads and cthreads

On Thu, Apr 26, 2001 at 03:57:53PM -0400, Roland McGrath wrote: > I had never anticipated anyone trying to implement pthreads for the Hurd > in any way but by a substantial rewrite of the libc hurd code. When pthreads will actually be implemented. Do you think it would be a good idea to r

Re: Interaction of pthreads and cthreads

On Thu, Apr 26, 2001 at 03:57:53PM -0400, Roland McGrath wrote: > I had never anticipated anyone trying to implement pthreads for the Hurd > in any way but by a substantial rewrite of the libc hurd code. Ah, okay. My initial thought had been to simply take MIT pthreads or something lik

Re: Interaction of pthreads and cthreads

I had never anticipated anyone trying to implement pthreads for the Hurd in any way but by a substantial rewrite of the libc hurd code. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Interaction of pthreads and cthreads

I've been hacking a bit at the pthreads problem. If(when) I get this right, should I do anything to be careful of the interaction between pthreads and cthreads? I notice that most of glibc is reasonably oblivious to threads, but the hurd directories use them alot. I'm concerne

Re: pthreads in hurd

On Wed, Feb 28, 2001 at 05:09:09PM +0100, Erik Verbruggen wrote: > I checked the *hurd archives, and as far as I can see, no-one is working > on pthreads for Hurd. Is that right? If this is the case, I hereby > volonteer to write a pthread-to-cthread wrapper "package". As

pthreads in hurd

Hi all, I checked the *hurd archives, and as far as I can see, no-one is working on pthreads for Hurd. Is that right? If this is the case, I hereby volonteer to write a pthread-to-cthread wrapper "package". As far as I can see, this shouldn't be too hard, as pthreads is more r