Pype.Clicker wrote:
what was rolling in /dev/brain is that it makes no sense to say 'everything is a file' if sometimes you can seek a file and sometimes you cannot...
Or, put directer, UNIX doesn't work according to "Make it as simple as it can be, but no simpler - Einstein". The dude was right.
Quote:
The unix approach says 'fifos, character devices, sockets are files ... they just cannot do everything a 'regular' file can!' while OOP programming would prefer 'fifos, character devices, sockets and files are all X ... but files can do more than what X can ...'
And if you model them as such in your c++ environment, as opposed to the current STL template idea (I think it models it the same, not sure), you'll have a more powerful OS.
PS: in some cases, I'd rather get event messages telling me something has happened. Input is one such things, it just makes no sense to have a pipe of inputs where a key being hit is an _event_, not an _input stream_.
Same for listening sockets, you don't block a thread on it actively, you let the app tell you it wants to "open that port for listening", and you then deliver messages to its inbox telling it that "there is a connection request from x.x.x.x:y to z.z.z.z@a, at time b", so you can reply as you should. Of course, it's even better if there's a default way to do popup threads, but my head is still munching the ideas around that. I'm now thinking about a handle_t defer(&function, ...) where the deferred function is executed at SOME time in the future, after which a signal is sent to that handle. If something is listening at the handle, it's awaken at the time of completion, so you can do more than one thing at once, without thread sync problems... Point is, how the **** do I write down that defer function without compiler warnings?