Fwd: Re: GTK threading on FreeBSD (and possibly otherunices)
I'm forwarding this from the GTK development list. According to Owen
their is something wrong with the threads implementation
Is that true? or is it a "It's not the way Linux works, so it must be
wrong"-pigheadedness? =)
DocWilco
"ROGIER MULHUIJZEN" [EMAIL PROTECTED] writes:
Hi,
After getting a bit more intimate with FreeBSD's implementation of
POSIX threads I had another stab at getting gFTP to work.
The problem I had (after fixing a rather simple compile error with
include files) is that file-transfers (which get their own thread) just
weren't moving. Except when I was doing stuff with the interface.
After checking gFTP's code I found that all it is rather well coded for
threading, and was using sleep(0) in all the right places. So I had a
look at the main loop, which was gtk_main(). Now that (AFAIK) doesn't
use a sleep(0). So I added it, and presto, gFTP ran as smooth as a
newborn baby.
What I did exactly was in gtkmain.c at line 476 I added:
if (g_main_is_running (main_loops-data))
{
GDK_THREADS_LEAVE ();
sleep(0);
g_main_run (loop);
GDK_THREADS_ENTER ();
gdk_flush ();
}
This change doesn't make much sense to me - when there is nothing
for the GUI thread to do, then the GUI thread is blocking in
select(). And if the main thread is blocking in select() and
your other threads aren't running, then you have a bug
in your threading implementation.
But this wouldn't be the right place to put it anyways, since
a) program is free to use g_main_run() directly without going through
gtk_main()
b) gtk_main() is only called once in a typical program, so this
really shouldn't have any effect.
Maybe you can explain more about why you think a sleep(0) is
necessary.
The reason I would expect to see this would be if you had one thread
that was constantly locking and unlocking a lock and you wanted to
give other threads a chance to get scheduled and grab the lock.
But putting a sleep(0) in this spot really shouldn't make any
difference, unless gFTP is constantly running recursive main
loops.
Now I'm pretty new to GTK's internals, so I'm not sure if the sleep is
in the right place or not.
The way I figured is:
- It should NOT be outside the LEAVE/ENTER statements, because they
translate to unlock and lock mutex. Sleeping after a lock and before an
unlock seems unhealthy to me
Well, sleeping inside the lock would absolutely no good if the
purpose of your sleep(0) is to give other threads a chance to
grab the lock.
- The gdk_flush should probably follow the g_main_run(loop) ASAP (not
sure what it does)
The flush() is basically there makes sure that pending X calls
get done before a program exits. (There is an implicit XFlush()
before GDK goes into a select(), but at this point, there may
be no subsequent iterations, so we need an explicit flush.
Regards,
Owen
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
Pthreads
Quick question, Does anyone on here know what the equivelant macro for PTHREAD_RECURSIVE_MUTEX_INITALIZER_NP is under freebsd? I cant find anything like this in pthread.h, and Im wondering without it what do I use to initialize a recursive mutex. Any advice would be appreciated Many thanks Andrew Alston Citec Network Securities (Director) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: GTK threading on FreeBSD (and possibly other unices)
On Thu, Jan 13, 2000 at 10:27:23AM +0100, ROGIER MULHUIJZEN wrote: I'm forwarding this from the GTK development list. According to Owen their is something wrong with the threads implementation Is that true? or is it a "It's not the way Linux works, so it must be wrong"-pigheadedness? =) Chances are that there is a bug in the application in question. Buggy threaded programs behave differently, depending on the underlying threads implememtation, so the brokenness may not be apparent on another platform. The email exchange that you forwarded doesn't give too much insight into what the problem is (at least not that I picked up). However, the fact that the author thinks sleep(0) is a good idea for encouraging thread switching isn't a good sign (i.e. the author probably doesn't have a good grasp on threaded programming), and makes me further suspect that the application in question is buggy. Chances are good that the application has one or more threads in a buzz loop, which is causing the GUI thread to starve. On Linux, the fact that threads are scheduled by the kernel may nice down the buzzing threads and make the application appear to be working okay. This is all highly speculative. Take it for what it's worth. =) Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: GTK threading on FreeBSD (and possibly other unices)
I'm forwarding this from the GTK development list. According to Owen their is something wrong with the threads implementation Is that true? or is it a "It's not the way Linux works, so it must be wrong"-pigheadedness? =) What version of FreeBSD are you using? Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: GTK threading on FreeBSD (and possibly otherunices)
I'm running 3.4-RELEASE. DocWilco Daniel Eischen [EMAIL PROTECTED] 01/13 12:57 PM I'm forwarding this from the GTK development list. According to Owen their is something wrong with the threads implementation Is that true? or is it a "It's not the way Linux works, so it must be wrong"-pigheadedness? =) What version of FreeBSD are you using? Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthreads
Quick question, Does anyone on here know what the equivelant macro for PTHREAD_RECURSIVE_MUTEX_INITALIZER_NP is under freebsd? I cant find anything like this in pthread.h, and Im wondering without it what do I use to initialize a recursive mutex. Any advice would be appreciated Well, the '_NP' in PTHREAD_RECURSIVE_MUTEX_INITALIZER_NP should give you some idea. Hint: Non-portable. There is no PTHREAD_RECURSIVE_MUTEX_INITALIZER_NP in the POSIX standard, and one shouldn't rely on its use. Recursive mutexes can be easily done by the application, just by wrapping them in a structure with an owner and count. That said, SUSv2 does provide a recursive mutex (unlike POSIX). To use a recursive mutex under FreeBSD, use: pthread_mutex_settype(PTHREAD_MUTEX_RECURSIVE); Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile
Consider as an example that open() is a thread cancellation point according to POSIX. If libpthread overrides the libc open() with its own version of open(), then by extension, every function that calls open() can potentially cause thread cancellation. This propagation of cancellation points is legal in a specified list of libc functions, but POSIX also says that *no* functions not in that list may act as cancellation points. That means that we have to be absolutely sure not to propagate cancellation points within libc, and short of constructing and analyzing a full call graph of the libc internals, this is the only way (that I can think of) to assure that libc doesn't incorrectly propagate cancellation points. Use _open internally within libc and libpthread. Have one "open" entry point that is the cancellation version of open. So, once we switch from libc_r to libpthread, we will have to implement, for example open() and _libc_open() in libpthread, where open() tests for cancellation, then calls into _libc_open(), which does the real work and presumably culminates in a call to _open(). In fact, we can probably make cancellation work correctly even in libc_r now, but I'll convert to libpthread first (the order these things are done in doesn't matter much). How are you going to handle locking inside libc, if the locking functions are not inside libc? Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: GTK threading on FreeBSD (and possibly other unices)
I'm running 3.4-RELEASE. Try upgrading to -stable and see if that helps. There were some changes recently merged from -current. If the application uses signals to wakeup threads, then perhaps the -stable version may fix the problems your seeing. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading the kernel sources
On 12/01 17:09, Michael Lucas wrote: Minesweeper can only fill so many hours in a day, after all. Must be a long day in your part of the world, then, because it's an NP-complete problem! (http://www.mat.bham.ac.uk/R.W.Kaye/minesw.htm) Heh :-) obSources: try /usr/src/sys/contrib/softupdates/ffs_softdep.c :-) best; gjvc -- [gjvc] 4.4BSD 4.ever! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rfork() [was: Concept check]
On Wed, 12 Jan 2000, Luoqi Chen wrote: It's almost a regular fork(), we lose all the advantages of a single address space. A rfork(RFMEM) wrapper can achieve the same level of usability without sacrificing the performance, and IMO is a preferred solution. I don't see this at all. You get many of the advantages of the single address space: everything is shared save the stack. Most people who have brought this up over the years want this type of behaviour, and find themselves having to hack it in user mode, and not enjoying the experience. I used this very version of rfork extensively for years for shared-memory programming and it was fine. Anyway, if I get to this it goes on my web page .. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
In message [EMAIL PROTECTED], "Kenneth D. Merry" writes: On Tue, Jan 11, 2000 at 13:49:59 -0600, Jonathan Lemon wrote: The RCC is probably this one: pci: unknown ATA vendor = 0x1166, device = 0x0211 I wonder why it flags it as a ATA device, I'm pretty sure this is the RCC chip -- the vendor id matches. (I checked this time.) It's proably the chip class or something. That could well be an IDE chip, though. Intel's chipsets usually include an IDE controller. Does anyone have a URL for "RCC"? I also want to know a URL. My NEC PC98 (using x86 CPU, but not PC-AT compatible) uses RCC Champion as it's chipset. (Sorry not Champion II/III, it's slightly old machine.) I'll attach dmesg from it. RCC Champion is attached like this. pcib0: Ross (?) host to PCI bridge on motherboard FreeBSD-3.2 (I'm not sure, 3.1?) was running fine too. NOKUBI Hirotaka Fingerprint20 = DEBC 0793 7CD6 92F1 0A1F A792 9E2F A41B 171D Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1994-1999 FreeBSD(98) porting team. Copyright (c) 1992 A.Kojima F.Ukai M.Ishii (KMC). Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Tue Dec 14 23:41:04 JST 1999 [EMAIL PROTECTED]:/usr/src/src/sys/compile/MP Calibrating clock(s) ... TSC clock: 265922163 Hz, i8254 clock: 2457598 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 2457600 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II (265.92-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 100638720 (98280K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00318000 - 0x05ff7fff, 97386496 bytes (23776 pages) avail memory = 94453760 (92240K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpint 7 - irq 8 IOAPIC #0 intpint 8 - irq 9 IOAPIC #0 intpint 9 - irq 10 IOAPIC #0 intpint 10 - irq 11 IOAPIC #0 intpint 11 - irq 12 IOAPIC #0 intpint 12 - irq 13 IOAPIC #0 intpint 13 - irq 14 IOAPIC #0 intpint 14 - irq 15 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00f4c40 bios32: Entry = 0xf5612 (c00f5612) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x1bb9b pnpbios: Found PnP BIOS data at 0xc00f51b0 pnpbios: Entry = d8000:3a Rev = 1.0 Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel.up" at 0xc02fc000. Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x8070 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=00051166) npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=00051166) pcib0: Ross (?) host to PCI bridge on motherboard found- vendor=0x1166, dev=0x0005, revid=0x00 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x1033, dev=0x003b, revid=0x01 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x1033, dev=0x0009, revid=0x02 class=03-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x9004, dev=0x6078, revid=0x01 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base 6800, size 8 map[14]: type 1, range 32, base 2000, size 12 found- vendor=0x8086, dev=0x1229, revid=0x02 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=3 map[10]: type 1, range 32, base 20001000, size 12 map[14]: type 1, range 32, base 6000, size 5 map[18]: type 1, range 32, base fed0, size 20 found- vendor=0x102b, dev=0x0519, revid=0x01 class=03-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base 20004000, size 14 map[14]: type 1, range 32, base 2300, size 23 pci0: PCI bus on pcib0 isab0: NEC 003B PCI to PC-98 C-bus bridge at device 6.0 on pci0 isa0: ISA bus on isab0 vga-pci0: NEC model 0009 PCI to PC-98 Core Graph bridge at device 7.0 on pci0 ahc0: Adaptec aic7860 SCSI
Re: rfork() [was: Concept check]
"Ronald G. Minnich" wrote: On Wed, 12 Jan 2000, Luoqi Chen wrote: It's almost a regular fork(), we lose all the advantages of a single address space. A rfork(RFMEM) wrapper can achieve the same level of usability without sacrificing the performance, and IMO is a preferred solution. I don't see this at all. You get many of the advantages of the single address space: everything is shared save the stack. Most people who have brought this up over the years want this type of behaviour, and find themselves having to hack it in user mode, and not enjoying the experience. I used this very version of rfork extensively for years for shared-memory programming and it was fine. One of the things that rfork(RFMEM) does in our implementation is to share the everything from the VM data structures down to the page tables themselves. In that sharing style, it isn't possible to have processes sharing everything but the stack, at least not without context switching PTD[] slots. We used to do this on SMP for the per-cpu pages which is what prevented us from doing RFMEM style threads on SMP boxes for so long as the same pmap page directory couldn't be loaded twice on different cpus. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile
On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: Use _open internally within libc and libpthread. Have one "open" entry point that is the cancellation version of open. This is what it appears Solaris 7 does. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile
On Thu, 13 Jan 2000, David O'Brien wrote: On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: Use _open internally within libc and libpthread. Have one "open" entry point that is the cancellation version of open. This is what it appears Solaris 7 does. Yeah, I've noticed that too. If you look at the CVS logs you can see that this was thought about back in '98: $ cvs log -r1.12 libc/i386/SYS.h [ ... ] description: revision 1.12 date: 1998/05/05 22:06:16; author: jb; state: Exp; lines: +9 -3 branches: 1.12.2; Build the syscalls (in libc, not libc_r) with weak symbols so that libpthread can override them as required. = I don't quite understand the need to have _libc_XXX variants. I think we should just use _XXX internally. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
I am new in this mail list, so I do not have so much experience about the questions I should ask, If I am in the worng place let me know, please. Well my question is related with Solaris 2.6, the story is like this: I have a Solaris 2.5 server which has configured all the printers so I can perint from that machine without any problem; The printers are remotes so I use the IP address on /etc/hosts ( Nis database ). Recently, I update the nis clients to Solaris 2.6, but I am not sure how to configure the printers, is there anybody there who can give me a hand?. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: your mail
On Thu, Jan 13, 2000, Ramiro Amaya wrote: I am new in this mail list, so I do not have so much experience about the questions I should ask, If I am in the worng place let me know, please. Well my question is related with Solaris 2.6, the story is like this: What does this have to do with the FreeBSD operating system? -- |Chris Costello [EMAIL PROTECTED] |Software is mind work. Having the right frame of mind is essential. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading the kernel sources
Wes Peters wrote: Michael Lucas wrote: I find myself in a contract where I sit for eight hours a day and wait for something to break. It pays obscenely well, so I'm putting up with the tedium. So, if I was to sit down and start reading /usr/src/sys, where's the logical place to start? Or should I start elsehwere? Or is there no logical statring place, and I should just assimilate it all en masse? Start with the PR database. Grab a PR, see if you can figure out what makes it go wrong, and then see if you can make it go right. Call this "directed research" of anyone asks what you're doing. Gut reaction: "Geez, I'd like to learn how to swim." "No problem! Just tie these cinderblocks to your wrists and ankles, jump off the deep end, and you'll be ready to go." Second reaction: Ah, what the hell. I might actually fix something. ==ml Remember, real hackers run -CURRENT on their laptops. ;^) PS: Anyone know the status of zp0 in -current? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading the kernel sources
On Thu, 13 Jan 2000, Michael Lucas wrote: PS: Anyone know the status of zp0 in -current? It was a hack and it was put to sleep by someone wielding an axe. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile
On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: Consider as an example that open() is a thread cancellation point according to POSIX. If libpthread overrides the libc open() with its own version of open(), then by extension, every function that calls open() can potentially cause thread cancellation. This propagation of cancellation points is legal in a specified list of libc functions, but POSIX also says that *no* functions not in that list may act as cancellation points. That means that we have to be absolutely sure not to propagate cancellation points within libc, and short of constructing and analyzing a full call graph of the libc internals, this is the only way (that I can think of) to assure that libc doesn't incorrectly propagate cancellation points. Use _open internally within libc and libpthread. Have one "open" entry point that is the cancellation version of open. It isn't adequate to only have two names with a libpthread. There has to be: 1) _open() -- A name to access the actual system call. 2) _libc_open() -- A name that libc uses internally which by default is the same as _open(), but can be overridden. 3) open() -- The name that an application uses (and cancellation point). As mentioned in my previous email, if we were to remove _libc_open() and use open() instead inside of libc, we would incorrectly propagate cancellation points. If we were to remove _libc_open() and use _open() instead inside of libc, then we would have the problem of some libc functions using system calls directly, where libpthread needs to do call conversion and/or extra bookkeeping work. (I experienced this problem in tests first-hand while doing the conversion; hence the renaming of functions in libc_r.) We can argue about names, but I don't see any way to get around having three names. That said, I get momentarily confused about this every time I have to think about it, so if I'm really missing something, please help me to figure it out. =) How are you going to handle locking inside libc, if the locking functions are not inside libc? I dunno. =) Seriously, I haven't given much thought to this yet, and can't claim to understand all the issues involved. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: your mail
On Thu, 13 Jan 2000, Ramiro Amaya wrote: I am new in this mail list, so I do not have so much experience about the questions I should ask, If I am in the worng place let me know, please. Well my question is related with Solaris 2.6, the story is like this: I have a Solaris 2.5 server which has configured all the printers so I can perint from that machine without any problem; The printers are remotes so I use the IP address on /etc/hosts ( Nis database ). Recently, I update the nis clients to Solaris 2.6, but I am not sure how to configure the printers, is there anybody there who can give me a hand?. Thanks Hi, Ramiro.. You are indeed in the wrong mailing list (and on the wrong server :-) [EMAIL PROTECTED] is, firstly, pertaining to the FreeBSD UNIX operating system, available on CD, or at ftp.cdrom.com in freely downloadable forms. This -hackers list is meant for the more technical array of questions and their responses. "More technical" generally means questions pertaining to the source code of the operating system itself. -- Ryan Thompson [EMAIL PROTECTED] 50% Owner, Technical and Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: your mail
This list is for FreeBSD, not Solaris. *==* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice* *All ORBS.org SMTP connections are denied! * *==* On Thu, 13 Jan 2000, Ramiro Amaya wrote: I am new in this mail list, so I do not have so much experience about the questions I should ask, If I am in the worng place let me know, please. Well my question is related with Solaris 2.6, the story is like this: I have a Solaris 2.5 server which has configured all the printers so I can perint from that machine without any problem; The printers are remotes so I use the IP address on /etc/hosts ( Nis database ). Recently, I update the nis clients to Solaris 2.6, but I am not sure how to configure the printers, is there anybody there who can give me a hand?. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile
On Thu, 13 Jan 2000, Jason Evans wrote: On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: Consider as an example that open() is a thread cancellation point according to POSIX. If libpthread overrides the libc open() with its own version of open(), then by extension, every function that calls open() can potentially cause thread cancellation. This propagation of cancellation points is legal in a specified list of libc functions, but POSIX also says that *no* functions not in that list may act as cancellation points. That means that we have to be absolutely sure not to propagate cancellation points within libc, and short of constructing and analyzing a full call graph of the libc internals, this is the only way (that I can think of) to assure that libc doesn't incorrectly propagate cancellation points. Use _open internally within libc and libpthread. Have one "open" entry point that is the cancellation version of open. It isn't adequate to only have two names with a libpthread. There has to be: 1) _open() -- A name to access the actual system call. 2) _libc_open() -- A name that libc uses internally which by default is the same as _open(), but can be overridden. I don't think we need 2) 3) open() -- The name that an application uses (and cancellation point). As mentioned in my previous email, if we were to remove _libc_open() and use open() instead inside of libc, we would incorrectly propagate cancellation points. Right, use _open instead. If we were to remove _libc_open() and use _open() instead inside of libc, then we would have the problem of some libc functions using system calls directly, where libpthread needs to do call conversion and/or extra bookkeeping work. (I experienced this problem in tests first-hand while doing the conversion; hence the renaming of functions in libc_r.) Forget about libc_r for the moment. It's on it's last breath. Think about the thread system proposed in -arch. It is OK to have libc make system calls directly, because when they block, you'll get an upcall in another context when libpthread is linked in. If libpthread isn't linked in, then the call just blocks. Having _libc_open() used internally within libc doesn't allow libpthread to override _libc_open() because the linker has already resolved references to _libc_open() within libc to the _libc_open() that is in libc, not the _libc_open() in libpthread. Boy, that looks and sounds awfully strange as I re-read it ;-) I think you'd have to modify the linker to make this work the way you envision - jdp could tell you better. We can argue about names, but I don't see any way to get around having three names. That said, I get momentarily confused about this every time I have to think about it, so if I'm really missing something, please help me to figure it out. =) I know, it confuses me a bit too ;-) I'm not 100% sure of the way the linker works, but my [last] understanding was that references to weak symbols within libc, would be resolved to libc, and that you couldn't override these from another library (libpthread). I hope that I'll be corrected if I've got this wrong. I'm not sure that it matters much anyways, because we don't need to override references to blocking system calls (at least with the proposed threading architecture). Some things will need to be overridden, though, such as locking mechanisms. I noticed that Solaris has all the pthread mutex/condvar calls in libc, and they're all weak symbols. They must be null bodies because if you write a program to lock a mutex twice (without linking in libpthread), you don't get an error and it doesn't hang on the second lock attempt. How are you going to handle locking inside libc, if the locking functions are not inside libc? I dunno. =) Seriously, I haven't given much thought to this yet, and can't claim to understand all the issues involved. I guess you'll learn :-) I can think of 2 different methods: 1. Locking routines would be fully implemented within libc. 2. Locking routines have null bodies in libc, and are implemented in libpthread, and a. Modify the linker to allow references to weak symbols within libc, to be overidden from libpthread, or b. Use function pointers to access the necessary functions which libpthread can overwrite with the fully implemented versions. I kind of like 2b because it seems easier. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Encryption rules changes coming up - win for open source
Matthew Dillon wrote: The last two paragraphs are the most relevant to us. http://www.nytimes.com/reuters/technology/tech-tech-encryption.html Have we had an opportunity to have the Walnut Creek (or other) legal staff review the actual rules for gotchas? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Encryption rules changes coming up - win for open source
Oliver Fromme wrote: Basically, does this mean something like tar cf - /usr/src/crypto | mail [EMAIL PROTECTED] ? :-) No. Mail to "[EMAIL PROTECTED]", Hilary is handling the database. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Encryption rules changes coming up - win for open source
Have we had an opportunity to have the Walnut Creek (or other) legal staff review the actual rules for gotchas? No, this is something I hope to sit down with our corporate counsel over very shortly. It's an annoying drive to San Jose from here, but I'm prepared to make that sacrifice. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Encryption rules changes coming up - win for open source
"Christopher R. Bowman" wrote: The last paragraph would be a step in the right direction but still seems silly. What are they going to do with it? I would really like to see people educate them on the stupidity of sending code to Washington. I think it would be neat if there was one of those blue ribbon campaign where on a flag day every one put all the open source encryption programs they could find up on their web pages, and then sent them to Washington, one to a floppy disk/envelope. It would be kinda neat if 1, 5, 10 or even a hundred thousand little envelopes with 1 floppy a piece showed up it the appropriate Washington office on the same day. Wonder how long the silly send a copy to Washington rule would remain after that. Forever. You are making the mistake of thinking they play to do something with all of this information. They do not, they play to print it out on greenbar paper and store it in some warehouse somewhere, along with all the extra B-17 toilet seats and WWI-vintage helmets and other piles of useless crap they own. Never underestimate the silliness of a beauracracy, for it is boundless. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
UDF
I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I was wondering if anybody was working on it. I'm thinking about trying to implement it for CD-RW's and would like to avoid duplication of effort and the anoyance of getting half way through the effort and having somebody else show up with a completed implementation. Brian Beattie| The only problem with [EMAIL PROTECTED] | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading the kernel sources
On Wed, 12 Jan 2000 17:09:29 -0500 (EST), Michael Lucas [EMAIL PROTECTED] wrote: I find myself in a contract where I sit for eight hours a day and wait for something to break. It pays obscenely well, so I'm putting up with the tedium. How does one go about getting such contracts? So, if I was to sit down and start reading /usr/src/sys, where's the logical place to start? In general, a good place to start is looking though the open PRs: pick one that looks interesting and either verify the enclosed fix or write one yourself. (This works best if you have a friendly committer who will commit the fixes for you). Given that -current is about a day away from a feature feeze, trying to break -current would also be useful (though this seems to be overly easy at present). Even more so if you can work out why it broke and how to fix it. Within -current, the major rough edges appear to be: - IPv6 (KAME): Testing would be much appreciated by Yoshinobu Inoue [EMAIL PROTECTED] - Soren's new ATA driver needs some bugs ironed out - it still has a tendency to get the system into a needs-a-power-cycle-to-fix state at times. - There is an interaction between Vinum RAID5 and softupdates that (AFAIK) hasn't been tracked down. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
In message [EMAIL PROTECTED] NOKUBI Hirotaka writes: : I also want to know a URL. : : My NEC PC98 (using x86 CPU, but not PC-AT compatible) uses : RCC Champion as it's chipset. (Sorry not Champion II/III, it's slightly : old machine.) I'll attach dmesg from it. : : RCC Champion is attached like this. : pcib0: Ross (?) host to PCI bridge on motherboard : : FreeBSD-3.2 (I'm not sure, 3.1?) was running fine too. Which version is busted? I might have broken it in my hacking on pccard if this is in -current. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading the kernel sources
Michael Lucas wrote: Wes Peters wrote: Michael Lucas wrote: I find myself in a contract where I sit for eight hours a day and wait for something to break. It pays obscenely well, so I'm putting up with the tedium. So, if I was to sit down and start reading /usr/src/sys, where's the logical place to start? Or should I start elsehwere? Or is there no logical statring place, and I should just assimilate it all en masse? Start with the PR database. Grab a PR, see if you can figure out what makes it go wrong, and then see if you can make it go right. Call this "directed research" of anyone asks what you're doing. Gut reaction: "Geez, I'd like to learn how to swim." "No problem! Just tie these cinderblocks to your wrists and ankles, jump off the deep end, and you'll be ready to go." Close. Leave off the cinderblocks, just jump in. Second reaction: Ah, what the hell. I might actually fix something. You might. Take your time, there's no hurry. ;^) PS: Anyone know the status of zp0 in -current? Having interrupt problems, at least on the 589D. Get an NE2000 clone. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fbsdboot.exe can't load elf kernels (flash cards off topic)
In message [EMAIL PROTECTED] Wes Peters writes: : Modern flash chips support on the order of 1,000,000 write cycles, so this : is not such a concern anymore. There is no reason why we shouldn't put : a filesystem on a flash card. We weren't talking about modern flash cards :-). These flash cards have 10,000 to 100,000 write cycles per page. : A better choice might be the flash disk cards from SanDisk and others, : since they do have an ATA interface and look like a small ATA drive : to the pccard code. Unless the linear flash cards are a LOT less : expensive, there isn't a lot of reason to do all the extra work. That's why I've done support for the ata flash cards, but haven't yet done the linear flash cards. :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
