Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"

[ketmar via Digitalmars-d-announce]

On Fri, 27 Mar 2015 22:37:21 +0000, weaselcat wrote:

> On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
>> On Fri, 27 Mar 2015 16:11:41 +0000, Ola Fosheim Grøstad wrote:
>>
>>> Not a broken design. If I have to run multiple servers just to handle
>>> an image upload or generating a PDF then you are driving up the cost
>>> of the project and developers would be better off with a different
>>> platform?
>>
>> but it is broken! the whole point of async i/o servers is that such
>> servers spend most of their time waiting for i/o. and if you need to do
>> some lengthy calculations, you either spawns a "real thread"
>> and commands it to wake you up when it is finished, or asking external
>> server to do the job (and wake you when it is finished).
>>
>> what moving fibers from thread to thread does is bringing in state
>> copying (we want our threads fairly isolated, aren't we? so either
>> copying, or ownership management).
>>
>> the whole thing of cooperative multitasking is to be... cooperative. in
>> several years some Shiny New Async Framework will use "no transferring
>> fibers between worker threads" as Spectacular Invention.
> 
> as an outsider to the web-scale world,
> this entire thing seems like a half-baked fork reimplementation

the whole "userspace threads" concept is a reimplementation of kernel 
threads and sheduling. ;-)

the main question is the amount of work required to switch between 
threads. if we have a little amount of threads that does heavy work, it's 
ok to use kernel mechanics: the time of context switching is neglible.

but it we have alot of threads that mostly waits for i/o, then does very 
little amount of work and waits for i/o again, context switching time 
starts to show itself. so we moving the whole "treading" thing to user 
application, thus minimising thread context switching time.

all in all this is a half-baked kernel thread reimplementation, yes. but 
it has it's own pros. and cons, of course: such as unresponsive user 
thread can block the whole app, like in good old windows 3 times.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20150327/9edbc13a/attachment.sig>