🚀 go-pugleaf

Dennis,

Thank you for the insight on the non-reentrant code and standard library
calls.
In brief, this server is a file server that enabled simple file transfers to
and from the machine it runs on.
The reason for using the standard library calls is that  a portion of the
code also runs on unix. I was trying to use portable code where possible.

Each thread receives one parameter: a socket descriptor from accept().

Each thread open()'s it's own file, and only access data related to that
file. It does not access any thing outside of private data. All the
functions are 'static' variable free.  All resources are closed, and finally
the socket descriptor is closed (closesocket())

The problem is that in some cases, a client will block waiting for a
response from it's associated server thread.
After looking at log files, I did find a function that had static variables
in it, which I fixed. But the server is having the same problem.
I thought that if any of the standard library open(), etc calls are not
thread safe, I might be running into the same problem.

Thanks again for the response and the help:)
CurtC





"Dennis Jones" <djones@nospam.com> wrote in message
news:3f3f0397$1@newsgroups.borland.com...
>
> "CC" <Xcurtc@tmscorp.com> wrote in message
> news:3f3d5a5b$1@newsgroups.borland.com...
> > Greetings All.
> > I have a TThread'ed program that uses open() close() access() and other
> > standard C library calls within the TThread object.
> >
> > I was wondering if anyone knows if doing this is thread safe with the
> > standard library functions? Not sure how the winapi under neath
implements
> > these functions.
>
> In general, standard library calls are thread-safe, unless they are known
to
> be non-reentrant.  A function such as strtok() is not thread-safe because
it
> not reentrant; that is, it uses a static local variable internally to
> maintain state between calls, and that variable would easily get clobbered
> by each thread that calls it.  In such a case, you would have to write
your
> own thread-safe version, or find one elsewhere.
>
> Where you run into trouble with threads in the standard library is not
> typically with the calls themselves, but with the resources accessed by
> those calls.  For instance, if you use open() to get a file handle and
then
> try to read() and write() that same file handle simultaneously in separate
> threads, you are going to have problems, because you will not have control
> over which thread is doing what at any given time.  And as you are no
doubt
> already aware (based on your other post), the role of the synchronization
> primitives is to prevent the simultaneous access of those resources.
>
> Of course, this also implies that if you are accessing a different
resource
> in each thread, there is (usually) no problem, because the threads are not
> competing for access to the same resource.
>
> Does this help?
>
> I'm curious...you are obviously not writing code that needs to be
> cross-platform compatible (based on your use of TThread), so why are you
> using the standard C calls open/close, rather than the Win32 calls,
> FileOpen/FileClose?
>
> - Dennis
>
>