You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by Mike Beckerle <mb...@apache.org> on 2023/01/06 17:56:14 UTC
Re: [jira] [Assigned] (DAFFODIL-2767) Mixed content with SAX unparsing hangs coroutine thread
So when using coroutines, the main code should be passed all exceptions. A
top level catch-throwable should surround all resumes on the peer coroutine
which should pass the object back to the waiting (always) main coroutine
which should rethrow it.
Since the two coroutines never run simultaneously (they are coroutines, not
threads) there should never be a case where this isn't sufficient.
On Fri, Jan 6, 2023, 9:51 AM Steve Lawrence (Jira) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/DAFFODIL-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Steve Lawrence reassigned DAFFODIL-2767:
> ----------------------------------------
>
> Assignee: Steve Lawrence
>
> > Mixed content with SAX unparsing hangs coroutine thread
> > -------------------------------------------------------
> >
> > Key: DAFFODIL-2767
> > URL: https://issues.apache.org/jira/browse/DAFFODIL-2767
> > Project: Daffodil
> > Issue Type: Bug
> > Components: Back End, Unparsing
> > Affects Versions: 3.4.0
> > Reporter: Steve Lawrence
> > Assignee: Steve Lawrence
> > Priority: Major
> > Fix For: 3.5.0
> >
> >
> > When unparsing with the SAX API, we spawn a new thread and run the
> unparse() call in that using our custom coroutine implementation. The main
> SAX thread and the coroutine unparse thread() using an ArrayBlockingQueue
> to suspend execution of one subroutine while the other executes.
> > However, if the main thread throws an exception then it leaves the
> corutine unparse() thread hung, blocked on the ArrayBlockingQueue.
> > This is exactly what happens if there is mixed content in the infoset we
> are unparsing. If mixed content is detected in the
> DaffodilUnparseContentHander startElement function then, then we throw an
> exception that can be caught by the SAX API, but the unparse thread is
> still running and blocked.
> > One option is to modify the startElement() function in the main thread
> to add state to a SAXEvent when it detects mixed content. When the unparse
> thread sees this state it can cause the unparse() thread to finish by
> throwing an exception. This will create an UnparseResult that eventually is
> passed back to the main thread and coroutine logic can finish.
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>
Re: [jira] [Assigned] (DAFFODIL-2767) Mixed content with SAX unparsing hangs coroutine thread
Posted by Steve Lawrence <sl...@apache.org>.
Yep, that's right.
On 1/6/23 1:00 PM, Mike Beckerle wrote:
> Ah, I reread this. I think I understand now.
>
> The coroutine is set up, started, but control is on the main thread, which
> hits an exception and the coroutine thread is left blocked.
>
> On Fri, Jan 6, 2023, 12:56 PM Mike Beckerle <mb...@apache.org> wrote:
>
>> So when using coroutines, the main code should be passed all exceptions. A
>> top level catch-throwable should surround all resumes on the peer coroutine
>> which should pass the object back to the waiting (always) main coroutine
>> which should rethrow it.
>>
>> Since the two coroutines never run simultaneously (they are coroutines,
>> not threads) there should never be a case where this isn't sufficient.
>>
>> On Fri, Jan 6, 2023, 9:51 AM Steve Lawrence (Jira) <ji...@apache.org>
>> wrote:
>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/DAFFODIL-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>> ]
>>>
>>> Steve Lawrence reassigned DAFFODIL-2767:
>>> ----------------------------------------
>>>
>>> Assignee: Steve Lawrence
>>>
>>>> Mixed content with SAX unparsing hangs coroutine thread
>>>> -------------------------------------------------------
>>>>
>>>> Key: DAFFODIL-2767
>>>> URL:
>>> https://issues.apache.org/jira/browse/DAFFODIL-2767
>>>> Project: Daffodil
>>>> Issue Type: Bug
>>>> Components: Back End, Unparsing
>>>> Affects Versions: 3.4.0
>>>> Reporter: Steve Lawrence
>>>> Assignee: Steve Lawrence
>>>> Priority: Major
>>>> Fix For: 3.5.0
>>>>
>>>>
>>>> When unparsing with the SAX API, we spawn a new thread and run the
>>> unparse() call in that using our custom coroutine implementation. The main
>>> SAX thread and the coroutine unparse thread() using an ArrayBlockingQueue
>>> to suspend execution of one subroutine while the other executes.
>>>> However, if the main thread throws an exception then it leaves the
>>> corutine unparse() thread hung, blocked on the ArrayBlockingQueue.
>>>> This is exactly what happens if there is mixed content in the infoset
>>> we are unparsing. If mixed content is detected in the
>>> DaffodilUnparseContentHander startElement function then, then we throw an
>>> exception that can be caught by the SAX API, but the unparse thread is
>>> still running and blocked.
>>>> One option is to modify the startElement() function in the main thread
>>> to add state to a SAXEvent when it detects mixed content. When the unparse
>>> thread sees this state it can cause the unparse() thread to finish by
>>> throwing an exception. This will create an UnparseResult that eventually is
>>> passed back to the main thread and coroutine logic can finish.
>>>
>>>
>>>
>>> --
>>> This message was sent by Atlassian Jira
>>> (v8.20.10#820010)
>>>
>>
>
Re: [jira] [Assigned] (DAFFODIL-2767) Mixed content with SAX unparsing hangs coroutine thread
Posted by Mike Beckerle <mb...@apache.org>.
Ah, I reread this. I think I understand now.
The coroutine is set up, started, but control is on the main thread, which
hits an exception and the coroutine thread is left blocked.
On Fri, Jan 6, 2023, 12:56 PM Mike Beckerle <mb...@apache.org> wrote:
> So when using coroutines, the main code should be passed all exceptions. A
> top level catch-throwable should surround all resumes on the peer coroutine
> which should pass the object back to the waiting (always) main coroutine
> which should rethrow it.
>
> Since the two coroutines never run simultaneously (they are coroutines,
> not threads) there should never be a case where this isn't sufficient.
>
> On Fri, Jan 6, 2023, 9:51 AM Steve Lawrence (Jira) <ji...@apache.org>
> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/DAFFODIL-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Steve Lawrence reassigned DAFFODIL-2767:
>> ----------------------------------------
>>
>> Assignee: Steve Lawrence
>>
>> > Mixed content with SAX unparsing hangs coroutine thread
>> > -------------------------------------------------------
>> >
>> > Key: DAFFODIL-2767
>> > URL:
>> https://issues.apache.org/jira/browse/DAFFODIL-2767
>> > Project: Daffodil
>> > Issue Type: Bug
>> > Components: Back End, Unparsing
>> > Affects Versions: 3.4.0
>> > Reporter: Steve Lawrence
>> > Assignee: Steve Lawrence
>> > Priority: Major
>> > Fix For: 3.5.0
>> >
>> >
>> > When unparsing with the SAX API, we spawn a new thread and run the
>> unparse() call in that using our custom coroutine implementation. The main
>> SAX thread and the coroutine unparse thread() using an ArrayBlockingQueue
>> to suspend execution of one subroutine while the other executes.
>> > However, if the main thread throws an exception then it leaves the
>> corutine unparse() thread hung, blocked on the ArrayBlockingQueue.
>> > This is exactly what happens if there is mixed content in the infoset
>> we are unparsing. If mixed content is detected in the
>> DaffodilUnparseContentHander startElement function then, then we throw an
>> exception that can be caught by the SAX API, but the unparse thread is
>> still running and blocked.
>> > One option is to modify the startElement() function in the main thread
>> to add state to a SAXEvent when it detects mixed content. When the unparse
>> thread sees this state it can cause the unparse() thread to finish by
>> throwing an exception. This will create an UnparseResult that eventually is
>> passed back to the main thread and coroutine logic can finish.
>>
>>
>>
>> --
>> This message was sent by Atlassian Jira
>> (v8.20.10#820010)
>>
>