You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Harry D. <hde...@ea...> - 2004-01-17 22:07:43
|
To whom it may concern, The attachment list the output of ./configure and make on my Debian "testing" machine. Sincerely, Harry Dellicker |
|
From: Doug R. <df...@nl...> - 2004-01-17 21:38:24
|
On Sat, 2004-01-17 at 18:30, Jeremy Fitzhardinge wrote: > On Sat, 2004-01-17 at 01:50, Doug Rabson wrote: > > On Sat, 2004-01-17 at 01:00, Jeremy Fitzhardinge wrote: > > > On Fri, 2004-01-16 at 01:51, Doug Rabson wrote: > > > > This happens automatically in the FreeBSD kernel. When a thread blocks > > > > in the kernel, an upcall to the userland thread scheduler happens and it > > > > switches to the next runnable thread. > > > > > > Ah, OK. That sounds like an interesting thing to virtualize when we > > > move to a threading model in which we expose virtual kernel interfaces > > > rather than just pthreads. > > > > That might be quite interesting indeed. It is possible that I might be > > able to get the kernel threading authors involved if necessary though > > since this stuff is fairly recent and is still being actively > > maintained. > > There's a tension between how we want to implement Valgrind and the > kinds of client programs we want to support. For Valgrind internally, > we'd like to use the most portable code and interfaces, so pthreads > rather than clone. But we want to support all the clients, including > those which use clone/rfork/upcalls directly. > > This means we need to do some things near the kernel interface to > virtualize all those things. For Linux with clone, signals are the only > real problem, and only in 2.4. Upcalls sound tricky; I don't know how > they work (any docs pointers?), but it seems that if the kernel does an > upcall, we need to intercept it, decide whether it is aimed at our > libpthread or at the client, and do the appropriate demultiplexing. There are some reasonable descriptions of the userland interface in the kse(2) manpage. I imagine a few of the hairy details might still be locked in the developer's heads but the manpage is a good place to get started. > > Given the large number of ways in which libpthread can be possibly > implemented, it means that using libpthread for Valgrind itself doesn't > necessarily give us any portability gains, because we still need to deal > with the raw kernel interface on the client's behalf. > > The question is whether using libpthread is a net gain or loss of > portability/complexity, and the answer isn't obviously clear to me. Well I don't expect any real programs except a pthread implementation to actually use these interfaces so perhaps its not a problem. On the other hand we don't get to interpose our own libpthread for statically linked programs. Regardless, I imagine the people implementing libpthread using the KSE syscalls might find it useful to have a version of valgrind that they can use to validate their work. > > Anyway, all the more reason to do a FreeBSD port, from my perspective. Right. > > > There is a shared-address-space fork which I used to get proxylwp > > working minimally on 4.x. I think the main problem with it as far as > > pthreads goes might be the signal routing thing that linuxthreads has - > > in fact there is a port of linuxthreads. The base system pthreads > > implementation is purely user-space threading. > > OK; what are rfork's signal semantics? Is it simply that signals arrive > at the process they're aimed at, with no shared signal state? Does the > existing signal router in vg_signals.c cope with this correctly? I think thats right but I haven't delved too deeply into it. I think the existing signal router should do the job - are there any valgrind test cases that test that particular feature? |
|
From: Jeremy F. <je...@go...> - 2004-01-17 19:30:14
|
On Sat, 2004-01-17 at 01:50, Doug Rabson wrote: > On Sat, 2004-01-17 at 01:00, Jeremy Fitzhardinge wrote: > > On Fri, 2004-01-16 at 01:51, Doug Rabson wrote: > > > This happens automatically in the FreeBSD kernel. When a thread blocks > > > in the kernel, an upcall to the userland thread scheduler happens and it > > > switches to the next runnable thread. > > > > Ah, OK. That sounds like an interesting thing to virtualize when we > > move to a threading model in which we expose virtual kernel interfaces > > rather than just pthreads. > > That might be quite interesting indeed. It is possible that I might be > able to get the kernel threading authors involved if necessary though > since this stuff is fairly recent and is still being actively > maintained. There's a tension between how we want to implement Valgrind and the kinds of client programs we want to support. For Valgrind internally, we'd like to use the most portable code and interfaces, so pthreads rather than clone. But we want to support all the clients, including those which use clone/rfork/upcalls directly. This means we need to do some things near the kernel interface to virtualize all those things. For Linux with clone, signals are the only real problem, and only in 2.4. Upcalls sound tricky; I don't know how they work (any docs pointers?), but it seems that if the kernel does an upcall, we need to intercept it, decide whether it is aimed at our libpthread or at the client, and do the appropriate demultiplexing. Given the large number of ways in which libpthread can be possibly implemented, it means that using libpthread for Valgrind itself doesn't necessarily give us any portability gains, because we still need to deal with the raw kernel interface on the client's behalf. The question is whether using libpthread is a net gain or loss of portability/complexity, and the answer isn't obviously clear to me. Anyway, all the more reason to do a FreeBSD port, from my perspective. > There is a shared-address-space fork which I used to get proxylwp > working minimally on 4.x. I think the main problem with it as far as > pthreads goes might be the signal routing thing that linuxthreads has - > in fact there is a port of linuxthreads. The base system pthreads > implementation is purely user-space threading. OK; what are rfork's signal semantics? Is it simply that signals arrive at the process they're aimed at, with no shared signal state? Does the existing signal router in vg_signals.c cope with this correctly? J |
|
From: Doug R. <df...@nl...> - 2004-01-17 09:50:30
|
On Sat, 2004-01-17 at 01:00, Jeremy Fitzhardinge wrote: > On Fri, 2004-01-16 at 01:51, Doug Rabson wrote: > > This happens automatically in the FreeBSD kernel. When a thread blocks > > in the kernel, an upcall to the userland thread scheduler happens and it > > switches to the next runnable thread. > > Ah, OK. That sounds like an interesting thing to virtualize when we > move to a threading model in which we expose virtual kernel interfaces > rather than just pthreads. That might be quite interesting indeed. It is possible that I might be able to get the kernel threading authors involved if necessary though since this stuff is fairly recent and is still being actively maintained. > > > It was an interesting exercise putting together a pthread proxylwp > > implementation but its certainly not the right solution for some > > systems. For example on FreeBSD 4.x there is no decent support for > > kernel threads and the userland threading library relies on intercepting > > all the blocking syscalls and using poll(2) in the thread scheduler to > > attempt to switch threads when they would block. > > Is that because FreeBSD 4.x doesn't have any kind of kernel-level > shared-address-space thread thing? Is it that the poll trick works for > looking at syscalls which block on FDs, but doesn't really help for > other types of blocking syscall? There is a shared-address-space fork which I used to get proxylwp working minimally on 4.x. I think the main problem with it as far as pthreads goes might be the signal routing thing that linuxthreads has - in fact there is a port of linuxthreads. The base system pthreads implementation is purely user-space threading. > > How important is FreeBSD 4.x as a target? I'm not quite sure. I might have some people who want FreeBSD 4.x support for their own use but they probably don't need complete support (probably not full pthreads support for instance). I'm still waiting to hear from them. |
|
From: Jeremy F. <je...@go...> - 2004-01-17 01:02:48
|
On Fri, 2004-01-16 at 01:51, Doug Rabson wrote: > This happens automatically in the FreeBSD kernel. When a thread blocks > in the kernel, an upcall to the userland thread scheduler happens and it > switches to the next runnable thread. Ah, OK. That sounds like an interesting thing to virtualize when we move to a threading model in which we expose virtual kernel interfaces rather than just pthreads. > It was an interesting exercise putting together a pthread proxylwp > implementation but its certainly not the right solution for some > systems. For example on FreeBSD 4.x there is no decent support for > kernel threads and the userland threading library relies on intercepting > all the blocking syscalls and using poll(2) in the thread scheduler to > attempt to switch threads when they would block. Is that because FreeBSD 4.x doesn't have any kind of kernel-level shared-address-space thread thing? Is it that the poll trick works for looking at syscalls which block on FDs, but doesn't really help for other types of blocking syscall? How important is FreeBSD 4.x as a target? J |