> But under Dos you would do simple polling, since the eventloop of your
own.
> The rest is event driven. (Dos can also be eventdriven, e.g. Turbo Vision,
> but the eventloop is under your control)
Yes, but doing that in DOS was not trivial. Where as in UNIX it's just a
fork away.
> While with mo
>
> > Hmm, I think this is more due to the move to event driven programming
> models
> > than cooperative multitasking.
>
> No, that is a hlf truth. Have you ever tried to write blocking tcp/ip code
> without threads?
Yes.
> It will block untill it receives the response. This completely* stops
> Hmm, I think this is more due to the move to event driven programming
models
> than cooperative multitasking.
No, that is a hlf truth. Have you ever tried to write blocking tcp/ip code
without threads? It will block untill it receives the response. This
*completely* stops the flow of the applic
> > Following works perfectly for me for many years:
> >
> > ioctl(Sock,FIONBIO,@tmp); // nonblocking
> >
> > All but one applications are single thread.
>
> Yes. You are using the 'work around'. Traditional UNIX sockets block.
> Microsoft (and others) realised this would not work with a co-operat
> Why must I use threads?
You must use threads in blocking tcp/ip else you will hang your application
everytime the network traffic slows or the application you connect to
(server?) does not immediately respond. Try changing your calls to blocking
and see what happens.
> Following works perfectly
> LG> yes, but... with other large TCP/IP libraries you MUST use threads...
> LG> with synapse you CAN use threads. This is mojor difference! One day
> LG> will be finished thread support in FPC and all will be happy. ;-)
>
> Why must I use threads?
Because not exists non-blocking large TCP/IP lib
