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

> > 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

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

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