Re: [TCLCORE] RE: Bug when transferring channels between threads

[<jy...@mo...>]

I strongly suggest to restrict the ability to transfer resources between
interpreters to only safe points during the execution. In the middle of
event processing is not safe! Trying to make it safe will cause the code
to become increasingly more complicated as more and more corner cases are
found and more and more concerns and sneaky interactions have to be
avoided/addressed.

Just my $0.02.

>>
>>
>> hi
>>
>> found another issue with multi-threading & channel transferring...
>>
>> scenario:
>> 	2 threads
>>
>> 	thread #1
>> 		create socket (-async mode)
>> 		protocol fsm enabled using 'fileevent'
>> 		after some dialog, the socket/channel is transferred
>> 		(using thread::transfer)
>> 		filevent's removed before transfer
>>
>> 	thread #2
>> 		thread::send request to create new socket/channel
>> 		immediately close the socket after receiving it
>> 		loop forever
>>
>> depending on the system load/timing the following happens:
>>
>> Tcl_NotifyChannel has been called from SocketEventProc to handle new
>> input which in turn starts processing the 'fileevent' actions attached
>> to the channel. One of these events causes the socket to be transferred.
>> At this point the originating thread no longer owns the socket. However
>> it performs an UpdateInterest operation,
>
> Ooops. Yeah, I believe I see what is happening.
>
>> and sometimes the channel is in
>> the middle of being closed and unstacked in a different thread!.
>>
>> The only check made is for a deleted (closed) channel (to avoid calling
>> UpdateInterest).
>>
>> What we need also is a clean way to determine that the channel was
>> transferred (cut & re-spliced elsewhere). In pathological cases this
>> could happen numerous times...
>>
>> possible solution comes to mind. add a counter to channel state which is
>> incremented every cut & splice. in Tcl_Notify, store the current count
>> before the filevent processing. then check if the number changed before
>> calling UpdateInterest.
>
>
>> I will try this...
>
> Hm. Would it not be enough to check if the managing thread of the channel
> is
> still the current channel ? And if not we know the channel has been
> transfered while the fileevents were executed.
>
> If more than one hevent handler is registered, and one of them does the
> transfer, I wonder if the others will still be invoked ? It should not, as
> the transfer explicitly clears all event handlers. ... But the loop in
> Tcl_NotifyChannel does not seem to be prepared for that possibility.
>
> IMHO we need some more test cases for this functionality.
>
> It is possible that the whole interaction of transfering with event
> handlers
> is un(der)specified/ I.e. that transfering only works if not done from
> withing a fileevent. ... It can be done from within a timer. IIRC we
> proscribe the use of a timer if you wish to transfer a newly created
> socket
> in the server callback (socket -sercver), because it is not allowed.
>
>
>
>> regards
>>
>> eric
>>
>>
>>
>
>
> --
> 	Andreas Kupries <andreask@ActiveState.com>
> 	Developer @ http://www.ActiveState.com, a division of Sophos
> 	Tel: +1 604 484 6491
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>