🚀 go-pugleaf

Hi Remy-

The thread does standard C library open(),close(),access(),read(),write()
calls only on file descriptors that it opened (for files), and send(),recv()
calls only on the socket descriptor it was passed. (The reason for using
standard libary calls is that I'm using code portable with unix)

From previous post I'm starting to think that my usage of file calls may not
be problem when used in a thread, since all data accessed passed to these
functions is internal to the TThread.

Should send() and recv() be thread safe also? I couldn't imagine them not
being.

You assistance it much appreciated.
CurtC



"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote in message
news:3f3d9f65$1@newsgroups.borland.com...
>
> "CC" <XXmailsink@aol.com> wrote in message
> news:3f3d7670@newsgroups.borland.com...
>
> > Does it sound resonable that one of these standard C
> > library calls could not be playing nicely with multiple
> > tthreads running at the same time?
>
> Only if multiple threads were accessing the same file/socket without
> synchronizing between them so that only 1 thread were accessing them at
any
> given time.
>
> > int TMyThread::myFileOpen(.......)
> > {
> >     int fd;
> >
> >     EnterCriticalSection(&cs)
> >     fd = open(.....);
> >     LeaveCriticalSection(&cs)
> >    return fd;
> >
> > }
>
> What exactly are you planning on doing with 'fd'?  All you've done is
> protect the initial opening the file.  Unless you are calling
> EnterCriticalSection() again, you are not going to be protecting the
> modifying of the file as well.  If you want to protect the file during the
> entire transfer, you should be calling EnterCriticalSection() when you
open
> the file and LeaveCriticalSection() after you have closed it.  Otherwise
you
> should rethink your design.
>
> > Also the same for read/writing sockets, writing files,etc.
>
> TServerSocket already performs locking operations internally to protect
> itself.
>
>
> Gambit
>
>