SES_Delete (#162)

[Poul-Henning Kamp]

In message <ujrve8y3qtn.fsf at false.linpro.no>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rg
rav?= writes:

>What it certainly *doesn't* do in any way, shape or form is guarantee
>that the session no longer has an object or VCL associated with it.
>In other words, this assertion will fail every time the client closes
>the connection before the completion of the current request.

It should absolutely not under any circumstances have an object associated,
as soon as an object is delivered, the session must deref the object and
it certainly should not have an object while in the care of the acceptor.

The sessions borrow their vcl from the worker thread, which keeps a
ref until it dies (or notices a new active VCL).  The code is in cnt_recv()
and cnt_done() respectively:

	cnt_recv():
		VCL_Refresh(&sp->wrk->vcl);
		sp->vcl = sp->wrk->vcl;
		sp->wrk->vcl = NULL;

	cnt_done():
		if (sp->vcl != NULL) {
			if (sp->wrk->vcl != NULL)
				VCL_Rel(&sp->wrk->vcl);
			sp->wrk->vcl = sp->vcl;
			sp->vcl = NULL;
		}

So there is no way that a session should be able to end up in the
acceptor with a vcl either.

To get to the acceptor, the session passes through the acceptor
pipe, written by:

	void
	vca_return_session(struct sess *sp)
	{

		CHECK_OBJ_NOTNULL(sp, SESS_MAGIC);
		AZ(sp->obj);
		AZ(sp->vcl);
		assert(sp->fd >= 0);
		assert(sizeof sp == write(vca_pipes[1], &sp, sizeof sp));
	}


Feel free to pierce this logic.

I have had asserts show me, that there were no obj or vcl in 
vca_return_session() and they were present on the receiving side
of the pipe in kqueue_acceptor.

I have not been able to find an explanation for that, that doesn't
involve a hardware or kernel error.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.