[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SocketService and SocketPort
From: |
David Sugar |
Subject: |
Re: SocketService and SocketPort |
Date: |
Sun, 6 Oct 2002 09:52:37 -0400 |
User-agent: |
KMail/1.4.3 |
Did this get missed earlier? We get a HUGE amount of junk mail attempts
through this list. It's very easy to miss a real pending message. I would
like to think about this...I know how I originally was thinking of what later
became SocketService; it was based on the coding model I was originally using
for channel ports in ACS.
On Sunday 06 October 2002 04:30, Byrial Jensen wrote:
> [Note: I sent my first message to the list a week ago when I was not
> yet subscribed to the list. I got a mesage back that it awaited
> moderator approval because it was posted by a non-member. However the
> moderator seems to be sleeping - at least I never saw my message at
> the list.]
>
> I have programmed a simple tcp proxy-server using Common C++ and
> have some experience and suggestions with regard to SocketService
> and SocketPort I would like to share:
>
> - There is currently no way to create SocketPorts for non-server
> connections. I would like a SocketPort constructor which creates
> an outgoing client tcp connection as I need a lot of such
> connections in a proxy server.
>
> - The virtual callback functions of the SocketPort class (expired,
> pending, output) may /not/ delete the current SocketPort object
> (*this) because SocketService::run will still use a pointer
> (SocketPort *port) to the object /after/ the return of these
> callback functions and thus use deallocated memory.
>
> This is not documented and it is disobeyed by the tcpservice.cpp
> demo program. So the demo program contains undefined behaviour!
>
> I would like that the callback functions are allowed to not only
> delete the current SocketPort object, but also to create new
> SocketPorts attached to the same SocketService and to delete
> other SocketPorts than *this, as this is useful in a proxy
> server. I have done it this way in my code (here implemented
> only inside "#ifdef CCXX_USE_POLL"):
>
> diff -udrpb commoncpp2-1.0.2-org/include/cc++/socket.h
> commoncpp2-1.0.2/include/cc++/socket.h ---
> commoncpp2-1.0.2-org/include/cc++/socket.h Tue Aug 27 04:11:07 2002 +++
> commoncpp2-1.0.2/include/cc++/socket.h Sun Oct 6 09:22:21 2002 @@
> -1814,6
> +1814,7 @@ private:
> bool detect_pending;
> bool detect_output;
> bool detect_disconnect;
> + volatile bool recent_changes;
>
> friend class SocketService;
>
> diff -udrpb commoncpp2-1.0.2-org/src/port.cpp commoncpp2-1.0.2/src/port.cpp
> --- commoncpp2-1.0.2-org/src/port.cpp Thu Jul 18 16:52:25 2002
> +++ commoncpp2-1.0.2/src/port.cpp Sun Oct 6 09:34:06 2002
> @@ -403,6 +403,7 @@ void SocketService::attach(SocketPort *p
>
> ++count;
> if(!first) first = port;
> + recent_changes = true;
>
> // start thread if necessary
> if (count == 1)
> @@ -438,6 +439,7 @@ void SocketService::detach(SocketPort *p
> port->service = NULL;
>
> --count;
> + recent_changes = true;
> leaveMutex();
> update();
> }
> @@ -533,6 +535,7 @@ void SocketService::run(void)
>
> MUTEX_START
> onEvent();
> + recent_changes = false;
> port = first;
> while(port)
> {
> @@ -544,19 +547,22 @@ void SocketService::run(void)
> port->detect_disconnect = false;
> p_ufd->events &= ~POLLHUP;
>
> - SocketPort* p = port;
> - port = port->next;
> - detach(p);
> - reallocate = true;
> - p->disconnect();
> - continue;
> + port->disconnect();
> + if (recent_changes)
> + break;
> }
>
> - if ( ( POLLIN | POLLPRI ) & p_ufd->revents )
> + if ( ( POLLIN | POLLPRI ) & p_ufd->revents ) {
> port->pending();
> + if (recent_changes)
> + break;
> + }
>
> - if ( POLLOUT & p_ufd->revents )
> + if ( POLLOUT & p_ufd->revents ) {
> port->output();
> + if (recent_changes)
> + break;
> + }
>
> } else {
> reallocate = true;
> @@ -573,6 +579,8 @@ retry:
> {
> port->endTimer();
> port->expired();
> + if (recent_changes)
> + break;
> goto retry;
> }
>
> - It would be more effective if SocketService::Run used the return
> values from the poll/select system calls.
>
> - TCPSocket does not support onAccept as claimed in the
> documentation. Yes, the function exists but it is not called by
> the SocketPort(SocketService *svc, TCPSocket &tcp) constructor.
>
> Best regards
> Byrial
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp