Re: Threads and my new job.
Firstly there is some threads discussion going on in -arch so I'm going to really reply to this over there.. This is just redirector mail julian On Mon, 22 Nov 1999, Jason Evans wrote: Walnut Creek has hired me as a full time employee to work primarily on improving and expanding FreeBSD's threads support. This is very exciting to me, and I hope my work will be of benefit the FreeBSD community. [chop] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
I will admit that I have had odd behaviours with threads in developing Lyris on FreeBSD that I have not seen on Solaris, NT, or Linux. I will see things like what appears to be the thread scheduler stop scheduling threads and just do a busy wait. I have not tracked it down any further for lack of time. -Kip On Wed, 24 Nov 1999, Nick Hilliard wrote: Why do we need to smite the Linux database servers? With threads in their current state they already outperform Linux's native threads by ~50x for things like sending mail. I would assume that the differences in database performance is similar. The threads ( the old nfs issues which have now thankfully been fixed) in their current state led bCandid to write about the Cyclone news router: : Issues the w/FreeBSD kernel and buggy threads have required our development : team to wait until improvements to the OS can be made. We did have a beta : posted on our website for a while but have since removed it. disclaimer: I am not a thread hacker. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
On Wed, Nov 24, 1999 at 01:31:44PM +, Nick Hilliard wrote: Why do we need to smite the Linux database servers? With threads in their current state they already outperform Linux's native threads by ~50x for things like sending mail. I would assume that the differences in database performance is similar. The threads ( the old nfs issues which have now thankfully been fixed) in their current state led bCandid to write about the Cyclone news router: : Issues the w/FreeBSD kernel and buggy threads have required our development : team to wait until improvements to the OS can be made. We did have a beta : posted on our website for a while but have since removed it. disclaimer: I am not a thread hacker. To this I would add that a number of commercial products currently available for FreeBSD depend on the Linux threads implimentation, notably Inktomis' depending on the future of the linux threads stuff, some diplomacy and vendor support may be necesary. What is the current status of the linux threads (Particularly with regard to SMP, which I recall was a problem)? How far from the userland bound original has libc_r moved ? Is the BSDi thread stuff completely seperate from all of this? -- GeoffB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
Jason, On Mon, Nov 22, 1999 at 06:52:20PM -0800, Jason Evans wrote: Walnut Creek has hired me as a full time employee to work primarily on improving and expanding FreeBSD's threads support. This is very exciting to me, and I hope my work will be of benefit the FreeBSD community. That's great. Is it part of your remit to maintain http://www.FreeBSD.org/threads/? That URL doesn't exist at the moment, but if we're going to have an active threads project, it probably should. Are you (or anyone else reading this, you don't have to be a committer at the moment) interested in keeping this section up to date? N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
[EMAIL PROTECTED] wrote: *) Lacking interfaces, such as pthread_cancel() (mentioned specifically in PR bin/7587) need to be implemented. It's good news for me. I hope to port xmovie -- QuickTime movie Player for Linux to FreeBSD. But I can not compile it under FreeBSD, because it's need pthread_cancel. xmovie http://heroine.linuxbox.com/xmovie.html MIHIRA Yoshiro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
Jason, you are my savior. Go forth and do much to create Truly Kick Ass Threading. Give me my tools to smite these Linux database servers once and for all! :-) Why do we need to smite the Linux database servers? With threads in their current state they already outperform Linux's native threads by ~50x for things like sending mail. I would assume that the differences in database performance is similar. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Threads and my new job.
Walnut Creek has hired me as a full time employee to work primarily on improving and expanding FreeBSD's threads support. This is very exciting to me, and I hope my work will be of benefit the FreeBSD community. There is a lot of work to be done in order to make FreeBSD's threads support truly excellent, and it will take more than just me working on it. Fortunately, there are a number of other people also interested in improving threads support, and as work progresses, I expect this will very much be a group effort. Some very fruitful long-range architecture discussions have been taking place on the -arch mailing list, and discussion will likely continue there for some time as design decisions are hashed out. If you are interested in participating in the design discussion, please subscribe to -arch (if you haven't already), read the -arch archives for the past couple of weeks to bring yourself up to speed on what has been discussed so far, read some of the more pertinent references listed throughout the discussion, then jump in. The signal-to-noise ratio on -arch is exceptionally high; please do your part in keeping it that way. What am I going to do? My first mandate is to round out the edges of our current libc_r and to bring it closer to standards compliance before 4.0. Specifically, I know that the following work is necessary: *) Address and close approximately 20 PRs. The list of PRs I know about is: i386/7426, bin/7587, misc/8202, bin/8281, kern/8729, misc/9778, misc/9903, misc/10599, bin/10992, kern/11982, kern/11984, bin/13008, misc/13117, kern/13644, misc/14264, i386/14383, kern/14685, and docs/14858. If there are other PRs that I didn't list that are directly related to threads, please let me know about them in private email so that I can keep track of them. *) Signal delivery fixes. I think Daniel Eischen has already taken care of this. *) Lacking interfaces, such as pthread_cancel() (mentioned specifically in PR bin/7587) need to be implemented. *) Make a real libpthread, rather than relying on the -pthread linker magic. This is high on Daniel Eischen's wish list, so maybe he already has something in the works. =) If you know of other outstanding issues that have a prayer of being addressed before 4.0 ships, please speak up. Jason Jason Evans [EMAIL PROTECTED] http://www.canonware.com/~jasone Home phone: (650) 856-8204 "I once knew a happy medium. Her name was Zohar." - James Foster To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
