More cluelessness: file descriptors and multithreading

More cluelessness: file descriptors and multithreading

Post by KJK::Hyperio » Sun, 20 Apr 2003 06:06:00



A terrible doubt: access to file descriptors from multiple threads is
serialized, or each thread gets a copy of the descriptors? I'd go for
serialization, but I'm not sure if it's the right approach
 
 
 

More cluelessness: file descriptors and multithreading

Post by Fletcher Glen » Sun, 20 Apr 2003 06:29:04



> A terrible doubt: access to file descriptors from multiple threads is
> serialized, or each thread gets a copy of the descriptors? I'd go for
> serialization, but I'm not sure if it's the right approach

A file descriptor is global and thread access is not limited
in any way.  It's up to you to use mutex's or other means to
insure that threads do not step on each other when accessing
a file.

--
                Fletcher Glenn


 
 
 

More cluelessness: file descriptors and multithreading

Post by Eric Sosma » Sun, 20 Apr 2003 06:34:43



> A terrible doubt: access to file descriptors from multiple threads is
> serialized, or each thread gets a copy of the descriptors? I'd go for
> serialization, but I'm not sure if it's the right approach

    File descriptors belong to the process as a whole,
and are thus shared by all the process' threads.  For
example, if thread T1 opens a file and gets f.d. 42,
thread T2 can then do fstat(42,&buf) without further ado.

    It's the kernel's job to ensure that nothing untoward
happens if T1 and T2 both call write(42,...) at "the same"
time.  How the kernel handles the necessary exclusion is
up to the kernel writer.

--

 
 
 

More cluelessness: file descriptors and multithreading

Post by KJK::Hyperio » Sun, 20 Apr 2003 07:04:52


Quote:> File descriptors belong to the process as a whole, and are thus
> shared by all the process' threads.

thanks. Another sign that I should ignore the "threads are lightweight
processes!" crowd completely

Quote:> It's the kernel's job to ensure that nothing untoward happens if T1
> and T2 both call write(42,...) at "the same" time.  How the kernel
> handles the necessary exclusion is up to the kernel writer.

that's all I needed to know. Thanks
 
 
 

1. "Bad file descriptor" with Bash; how to designate descriptors?

I have a trivial script which tails multiple files by
spawning a 'tail' process for each file and duping the
output into one file descriptor which is then tailed:

  for f in $*; do
        tail -1f $f >&3 &
  done

  exec <&3
  tail -f

This works fine under Sun ksh, but I've just tried to run
it now with Bash under Linux 2.4.16, only to have each
command using file descriptor 3 fail with a

  'Bad file descriptor'

error.

This has caught me completely unawares.  The bash manpage
says that

  "If the digits in word do not specify a file descriptor open
  for output, a redirection error occurs"

How do I open file descriptor 3 for output?  Or, if I do
something like

  tail -1f file > /dev/null &

how can I find out what file descriptor is opened so I can
direct the output of further tail commands to the same
descriptor?  What's the magic that bash needs to be able to
do something like this?

Many thanks,

Brad

2. dnotify fix for readv/writev (Linux 2.4.20)

3. Matrox Mystique ands X.

4. Apache and VirtualHost

5. portable way to convert FILE ptr to file descriptor?

6. Network Monitoring

7. how to get file length from file descriptor

8. RealAudio Player with SB 2.0 (/dev/mixer?)

9. *FILE and int as file descriptors.

10. Grabbing file from file descriptors

11. FILE descriptor and file id conversion?

12. difference b/w file pointer and file descriptor

13. kernel: Cannot read proc file system: 9 - Bad file descriptor