file desctiptors in linux and multithreading - Linux

This is a discussion on file desctiptors in linux and multithreading - Linux ; Hello, I am interested whether I can do connect() from different threads concurently. I found that doing close() from different threads on same fd, does nasty things, so ..does it applies to connect() ? Is it possible connect() to return ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: file desctiptors in linux and multithreading

  1. file desctiptors in linux and multithreading

    Hello, I am interested whether I can do connect() from different
    threads concurently.
    I found that doing close() from different threads on same fd, does
    nasty things, so ..does it applies to connect() ?
    Is it possible connect() to return same fd to concurent threads?
    Does libc has any concurency protection, if does ..from when? I am
    using is rather old libc-2.3.5.
    Or I just have to protect with mutexes all syscall functions?
    Thank you very much, in advance

    Dragomir

  2. Re: file desctiptors in linux and multithreading

    On Oct 29, 9:10*am, Drago wrote:

    > Hello, I am interested whether I can do connect() from different
    > threads concurently.


    Yes, just not on the same file descriptor.

    > I found that doing close() from different threads on same fd, does
    > nasty things, so ..does it applies to connect() ?


    You cannot release a resource in one thread while another thread is or
    might be using it. the results are unpredictable.

    > Is it possible connect() to return same fd to concurent threads?


    No, since 'connect' doesn't return an fd. Perhaps you meant 'accept'?

    > Does libc has any concurency protection, if does ..from when? I am
    > using is rather old libc-2.3.5.
    > Or I just have to protect with mutexes all syscall functions?
    > Thank you very much, in advance


    You don't need to protect syscall functions with mutexes. You only
    need to prevent specific cases that cause problems. For example, two
    threads cannot 'write' to the same TCP socket at the same time, as
    their data might be sent in an arbitrary order or interleaved. Two
    threads cannot 'read' from the same TCP socket at the same time for
    the same reason.

    DS

  3. Re: file desctiptors in linux and multithreading

    > > Is it possible connect() to return same fd to concurent threads?
    >
    > No, since 'connect' doesn't return an fd. Perhaps you meant 'accept'?
    >

    Thank you,
    yes, I ment socket()
    I have very strange lock-ups in all my threads, of my server app. some
    of them stack corrupt, but all of them seem to be locked in:
    0xb7e02c49 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
    I suspect problem with socket filedescriptors

  4. Re: file desctiptors in linux and multithreading

    I found the problem. Thank you David.
    It appeared i misused pthread_cancel() . It probably made the threads
    to stop on some of the cancellation points on socket operations.
    This made thread stopping unpredictable, so I get rid of cancellation
    at all. Made flag when thread need to stop, and exit from main loop if
    it is true.
    I hope this helps to anybody ..an use cancellation with caution

  5. Re: file desctiptors in linux and multithreading

    On 2008-11-11, Raphael Mankin wrote:

    > If you want proper isolation you must use separate
    > *processes*, not threads, i.e. call fork() not
    > pthread_create(). You will then have total isolation and can
    > do what you like. The flip side is that communication between
    > processes is trickier than between threads.


    Communication between processes takes more work, but it's
    harder to get it wrong in subtle ways: if it works, it's
    probably right. Communication between threads is trivial to do
    but it's also easy to do incorrectly such that it fails in
    subtly and infrequently.

    --
    Grant Edwards grante Yow! Let me do my TRIBUTE
    at to FISHNET STOCKINGS ...
    visi.com

+ Reply to Thread