Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Date: Fri, 15 Jun 2007 21:49:16 +0200
From: Filip Hanik - Dev Lists <devlists@hanik.com>
Subject: Re: Proposed simplification of CometEvent
In-reply-to: <4672E788.6020104@hanik.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Message-id: <4672ED3C.5060106@hanik.com>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 8BIT
References: <46681613.4040903@apache.org>
 <96e4b5230706111147w1d06043ew6b041453139778c@mail.gmail.com>
 <4670288F.10605@hanik.com>
 <96e4b5230706131217i61fa1a3cl33ea30407b62962c@mail.gmail.com>
 <46704E0D.4000708@hanik.com>
 <96e4b5230706131702s69f1f198s127ab1975d661a88@mail.gmail.com>
 <467192BF.1050607@hanik.com>
 <96e4b5230706141433m6fb4221l19fa3f660193993c@mail.gmail.com>
 <4672B9D5.60804@hanik.com> <4672BD2B.5060809@apache.org>
 <96e4b5230706151112g26fe7a63ic9234d6b1358325d@mail.gmail.com>
 <4672E788.6020104@hanik.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)

since we are getting pretty far off track here, I've started a Wiki page 
on what comet is and isn't.
http://wiki.apache.org/tomcat/WhatIsComet

It will be helpful in the future, or we can assimilate this into our 
docs eventually, but for now, I think it is a good drawing board to 
clear out things as we agree on them

Filip


Filip Hanik - Dev Lists wrote:
> Costin Manolache wrote:
>> Ok, so let me double check: the low level socket in sandbox is 
>> allways read
>> after a poll() / select(),
>> and never with a blocking read() ?
> huh? :)
>
>>
>> After the poll(): the Comet servlet, in a tomcat thread will be able 
>> to call
>> read() in the input
>> stream, and that will return data or 0 if no more data is available ( 
>> or -
>> call isReadable() and then read(),
>> or whatever else - but the socket will not be put in blocking mode ) ?
> and some more huh :)
>
> it is an implementation detail if the socket is blocking or non 
> blocking, and has nothing to do
> with read() returning 0 or not.
>
> now we are talking about the implementation, not the API. I can 
> implement inputstream.read() to return 0 on both blocking and non 
> blocking sockets.
> btw, for the NIO connector, we only have non blocking sockets, the API 
> is an abstraction from the socket layer,
>
>>
>> If this is true for sandbox - big +1.
> not sure how the above relates to sandbox or trunk, since they use the 
> same sockets the same way.
> Filip
>>
>> Costin
>>
>> On 6/15/07, Remy Maucherat <remm@apache.org> wrote:
>>>
>>> Filip Hanik - Dev Lists wrote:
>>> > Please note, that neither Remy nor I have yet really talked about non
>>> > blocking reads, so you might think sandbox is non blocking, well 
>>> it is
>>> not.
>>> > It is buffering, but not non blocking. a true non blocking read, 
>>> would
>>> > require a rewrite of all the buffer filters to keep state between 
>>> read
>>> > invocations.
>>>
>>> It is non blocking, as the low level read is always non blocking (in 
>>> the
>>> sandbox design).
>>>
>>> Rémy
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 
>> 269.8.15/848 - Release Date: 6/13/2007 12:50 PM
>>   
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org