mbeckerle commented on PR #879: URL: https://github.com/apache/daffodil/pull/879#issuecomment-1374326315
> > Can this be set small enough as to enforce sequential behavior, i.e., no parallelism between the caller of the content handler and the unparser? > > With this approach, no. Even with the batch size tunable is set to 1, the ContentHandler and SAXInfosetInputter can (and likely will) both do work a the same time. The ContentHandler will be preparing the next event while the SAXInfosetInputter is unparsing using the current event. Re-studying this PR briefly. I thought that when an event was queued for the peer co-routine, the main thread then would read from the reply queue, hence blocking itself until the peer replies back to it. That was the notion for how the two coroutines never overlap in doing work. Is it not functioning that way now? As I have tried to emphasize before, the goal, in fact the whole point of coroutines, is that it is a "call" that includes changing stacks too, but there is NO parallelism any more than there is when you call a procedure. Coroutines are a means of doing an inversion-of-control from push-to-pull or vice versa, but are not supposed to have any thread-safety implications, so both main and peer coroutines may run non-thread-safe code (if they want to) because there is not any concurrency. From other things I have read online, it seems there is quite high overhead to Java thread switching. People have ventured opinions like the whole point of co-routines is lost if you have to use kernel interfaces to implement it. But how else are you supposed to do this control inversion from push to pull without it? Note that once we get to Java 19, there is a new non-kernel threads thread system for Java which could reduce the context switching overhead substantially. https://blogs.oracle.com/javamagazine/post/java-loom-virtual-threads-platform-threads. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
