>
> > 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 the
> *flow of the application, be it DOS, WinAPI, VCL, or
> some exotic home brew GUI toolkit.
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)
E.g.
repeat
a:=select(...); //block but maximal n msec.
if (a) Then // if a not timed out
Event:=TranslateTCPIPEvent(A)
else
Event:=PollEventKeyBoardMouse();
If Event=filled Then
Dispatchevent(Event);
{$ifdef Win31}
ProcessMessages():
{$endif}
until Event=quit;
While with most other OSes/toolkits the OS/toolkit has the eventloop, and
you only provide callbacks and msghooks.
> Now consider M$ Windows 3.1. It had no threaded capability and only very
> crude methods for yielding to other processes. This is the reason that M$
> opted for non-blocking api, and the fact that it eased the event driven
> model was a bonus rather than a goal.
But TCP/IP and blocking/non-blocking existed before Windows (and probably
will exist after). Maybe win3.1 that had some effect on the Windows api,
but not on TCP/IP as a whole.
> If your app on Win3.1 didn't yield to other processes, you locked Windows.
This means that your app can't be 100% blocking. However that doesn't mean
you need to have threads. You app must deblock once every second or so and
process messages/yield.
_______________________________________________
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
