On Wed, 15 Sep 2004 Carlo Wood wrote:
On Wed, Sep 15, 2004 at 04:05:00PM -0400, Hugo Duncan wrote:
The proactor and reactor classes in giallo know nothing of sockets etc, and they can run in whichever thread you want.
I cannot imagine at the moment how this would work :/ (see my previous post)
On Wed, 15 Sep 2004 Carlo Wood wrote:
On Wed, Sep 15, 2004 at 04:55:05PM -0400, Hugo Duncan wrote:
documentation is sorely lacking... but giallo adds a level of indirection to what I have understood of your current thinking:
reads, writes etc are not directly initiated by the demultiplexer, rather by the connection class, which is responsable for combining the socket (pipe, or whatever else) class with the demultiplexer, hiding the details of which demultiplexer is used and ensuring the socket is in the correct blocking/non-blocking/ asynch mode.
Ok, I considered that to be obvious.
Ok, so I seem to have misunderstood what you were asking.
1) An object that encapsulates the 'device' abstration.
in giallo, this is the socket class.
2) A way to request more data (this exists of a function call to which the user provides a buffer pointer, and the size of that buffer)
in giallo, this is "connection<>::recv".
3) An entry point for a thread to call to 'sleep/wait'.
in giallo, after calling send/recv the calling function just returns. notification is always of completion and is not necessarily in the same thread.
4) A callback (or completion) function that is called when a new packet was received.
in giallo, user callback is attached to connection
It should be possible that point 4) is *entirely* handled in the user code, the only thing that the user wants it get control of the thread again once data is available. The user then can examine the received data, manage its own buffering and decide to either decode a message and handle it - or to leave the partial message in the buffer and request for more data.
that is how the connection class in giallo works. it contains no "buffer management".
Only once we have this interface we can provide "convenience" classes that do buffering for the user as well. And even think about providing protocol decoders too for common types of protocols (text, envelloped binary, fixed message sizes etc).
agreed. Hugo