psomogyi at gamax.hu
Mon Nov 20 08:41:45 GMT 2006
On Saturday 18 November 2006 22:46, tridge at samba.org wrote:
> our epoll/select we would need a small hack to verbs to expose the
> channel->fd file descriptor so we can add it to the list of fd's that
> we watch.
That was my 1st proposal (not published), and then after Alexander B. exposed
me the need of _real_ a socket-like interface (2nd) - at the cost of extra
overhead to emulate it fully or almost fully - I accepted the 2nd approach.
1st) : having channel->fd (which is a read-fd, and it yet has to be filtered
for the correct read event) public to your common event-handler
(select/poll), + having a filter-function (e.g. "ibw_can_recv")
Pros: fast & direct + easier to implement (this layer)
Cons: hard to use + high risk of not handling _each_ event _in time_.
(You can see this if you rollback the wiki link below...)
2nd) : current http://wiki.samba.org/index.php/CTDB_Project_ibwrapper.
(I'm going to modify this to datagram-like right now rather than streams,
It would have a need of a dedicated process for ib-specific event handling,
communicating to other user processes via e.g. unix domain sockets (or
Pros: safer to handle ib-specific events
Cons: more time to implement:) + emulation overhead
Based on your responses I assume I shall rollback to my 1nd approach.
Q1: how do you imagine [TCP/IP-] connection buildup? AFAIK the common design
is to dedicate 1 (forked) process for each connection (as samba works now).
I'd need a scenario for adding a node runtime as well.
Q2: can you provide guarantee that the main event loop won't be blocked or
time consuming at all? (I can imagine this only by performing operations -
with various exec time - in a different thread/process than the multiplex
That's why I've been curious where (and how) this layer is applied
More information about the samba-technical