Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 Apr : Re: TIdTCPServer - threads, global data contd.
| Subject: | Re: TIdTCPServer - threads, global data contd. |
| Posted by: | "Martin James" (mjames_falc..@dial.pipex.com) |
| Date: | Sun, 16 Apr 2006 06:24:07 |
"Stephen Odgaard" <sso@cowi.dk> wrote in message
news:44418887$1@newsgroups.borland.com...
> Trying to answer some of my own questions. (please correct me if im wrong
or
> an unsafe route)
> I should just mention that im using Indy v. 10
>
> It seems the key to 1a) and 1d) would be to maintain a TThreadlist of
> connected TIDContext's with their individual data.
> 1c) should then be possible to perform by getting the AContext from the
> TThreadlist above and then a) either executing the AContext.OnRun event,
or
> b)even simpler by executing AContext.Connection.IOHandler.WriteLn()
>
> Is the above understanding/approach correct and safe?
Sort of. You should not issue any call that might block from inside a lock.
Doing so allows the possibility that an interrupted connection, (eg. crashed
client, or cable fell out of router), could cause the write call to block
for an extended period. During this period, your app would be stuck because
nothing else could get at the list. If you get the context from the list
and then unlock the list before attempting the write, there is the
possibility that the client may disconnect and the context be freed before
the write starts, resulting an an AV. I'm afraid that Indy is a but awkward
to use in this respect.
IMHO, it's much safer overall if the data can be queued, rather than
attempting direct writes.
Rgds,
Martin
none