每个线程都进行申请文件描述符的操作的话，会不会发生文件描述符申请冲突？

[netxuning]

比如线程a所连接远程服务器的socket为18，同时b所连接的也是18。如此造成冲突?

[linqzly]

不会的，每个进程的资源是独立的，不会发生相互的冲突的

[dai_weitao]

服务器端一个socket负责连接和确认. 并会为客户端打开不同的端口, 不会造成冲突.

[netxuning]

谢谢两位

不过我的程序要连接不同的服务器，这样也不会吗？

[cceczjxy]

线程的话,就会冲突了吧

[dai_weitao]

连接不同服务器更不会了, 因为connect之后会返回一个socket filedes, 你connect到两个服务器也就返回两个socket filedes, 不会冲突.

[netxuning]

//以下是我从别的软件上抄下来的，实现对一个函数的超时控制，但是无法用在多线程环境下。
//怎样才能在多线程环境下对一个过程进行超时控制呢？

#include <stdio.h>
#include <setjmp.h>
#include <signal.h>
#include <errno.h>
#include <assert.h>

#define SETJMP(env) sigsetjmp(env, 1)

static sigjmp_buf run_with_timeout_env;

static void
abort_run_with_timeout (int sig)
{
assert (sig == SIGALRM);
siglongjmp (run_with_timeout_env, -1);
}

/* Arrange for SIGALRM to be delivered in TIMEOUT seconds. This uses
setitimer where available, alarm otherwise.

TIMEOUT should be non-zero. If the timeout value is so small that
it would be rounded to zero, it is rounded to the least legal value
instead (1us for setitimer, 1s for alarm). That ensures that
SIGALRM will be delivered in all cases. */

static void
alarm_set (double timeout)
{
/* Use the old alarm() interface. */
int secs = (int) timeout;
if (secs == 0)
/* Round TIMEOUTs smaller than 1 to 1, not to zero. This is
because alarm(0) means "never deliver the alarm", i.e. "wait
forever", which is not what someone who specifies a 0.5s
timeout would expect. */
secs = 1;
alarm (secs);
}

/* Cancel the alarm set with alarm_set. */
static void
alarm_cancel (void)
{
alarm (0);
}

/* Call FUN(ARG), but don't allow it to run for more than TIMEOUT
seconds. Returns non-zero if the function was interrupted with a
timeout, zero otherwise.

This works by setting up SIGALRM to be delivered in TIMEOUT seconds
using setitimer() or alarm(). The timeout is enforced by
longjumping out of the SIGALRM handler. This has several
advantages compared to the traditional approach of relying on
signals causing system calls to exit with EINTR:

* The callback function is *forcibly* interrupted after the
timeout expires, (almost) regardless of what it was doing and
whether it was in a syscall. For example, a calculation that
takes a long time is interrupted as reliably as an IO
operation.

* It works with both SYSV and BSD signals because it doesn't
depend on the default setting of SA_RESTART.

* It doesn't require special handler setup beyond a simple call
to signal(). (It does use sigsetjmp/siglongjmp, but they're
optional.)

The only downside is that, if FUN allocates internal resources that
are normally freed prior to exit from the functions, they will be
lost in case of timeout. */
/*控制函数指针fun所指向的函数fun(void* arg)运行的时间timeout*/

int
run_with_timeout (double timeout, void (*fun) (void *), void *arg)
{
int saved_errno;

if (timeout == 0)
{
fun (arg);
return 0;
}

signal (SIGALRM, abort_run_with_timeout);
if (SETJMP (run_with_timeout_env) != 0)
{
/* Longjumped out of FUN with a timeout. */
signal (SIGALRM, SIG_IGN);
return 1;
}
alarm_set (timeout); /*set alarm. */
fun (arg);

/* Preserve errno in case alarm() or signal() modifies it. */
saved_errno = errno;
alarm_cancel (); /*don't timed out, fun() has been over. then destroy the alarm. */
signal (SIGALRM, SIG_IGN);
errno = saved_errno;

return 0;
}

void
myfun (void *arg)
{
sleep (10);
}

int
main ()
{
run_with_timeout (10.0, myfun, NULL);
}

[netxuning]

上边代码发错地方了...