On Fri, 1 Dec 2023 16:49:30 GMT, Anton Bobrov wrote:
>> This patch addresses the issues described in the
>> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
>> signalling around libpipewire thread loop condition variables and also
>> fixing libpipewire error detecti
On Fri, 1 Dec 2023 16:54:34 GMT, Anton Bobrov wrote:
>> I think it's better to do it in the native, to avoid extra native-java hops.
>>
>> As for the number of extra attempts, I think one-two is enough.
>>
>> Something like this (I haven't tested it thoroughly yet):
>>
>>
>> diff --git
>> a/
On Fri, 1 Dec 2023 16:49:30 GMT, Anton Bobrov wrote:
>> This patch addresses the issues described in the
>> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
>> signalling around libpipewire thread loop condition variables and also
>> fixing libpipewire error detecti
On Fri, 1 Dec 2023 15:00:50 GMT, Alexander Zvegintsev
wrote:
>> @azvegint do you think it would make sense to do it in the native code or in
>> the upper level Java code ? AND also how many times do you think it would
>> make sense to retry provided this could be a permanent pipewire error and
> This patch addresses the issues described in the
> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
> signalling around libpipewire thread loop condition variables and also fixing
> libpipewire error detection and signalling and propagation to the screencast
> API.
> This patch addresses the issues described in the
> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
> signalling around libpipewire thread loop condition variables and also fixing
> libpipewire error detection and signalling and propagation to the screencast
> API.
On Fri, 1 Dec 2023 14:26:39 GMT, Anton Bobrov wrote:
>> Sorry for not being clear, I meant by retry to start everything with a new
>> session.
>> And of course, changing the internal API is not a problem as it is quite
>> small and only used in one place.
>>
>> Separate patch is fine, I submit
On Fri, 1 Dec 2023 14:19:25 GMT, Anton Bobrov wrote:
> WG21 is C++ standard and this is not
Oops, I meant WG14, of course.
> if you feel strongly about it (I don't) I can drop 'volatile' from both
> variables if that helps.
I do. However, formally I am not a reviewer.
-
PR Revie
On Fri, 1 Dec 2023 14:00:59 GMT, Alexander Zvegintsev
wrote:
>> @azvegint Thanks for reviewing this Alexander! I dont think re-trying here
>> is gonna work at all. The libpipewire docs leave a lot to be desired so I
>> was using their code as reference for this patch and according to their
>>
On Fri, 1 Dec 2023 13:44:21 GMT, Maxim Kartashev wrote:
>> @mkartashev hey, a fellow Sun comrade! (i still have my Sun badge too) :)
>>
>> This is for similar reasons to the existing 'sessionClosed' being volatile
>> ie bc multiple threads can read/write it and in this particular case a
>> lim
On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov wrote:
> This patch addresses the issues described in the
> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
> signalling around libpipewire thread loop condition variables and also fixing
> libpipewire error detection
On Fri, 1 Dec 2023 09:34:35 GMT, Anton Bobrov wrote:
>> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 930:
>>
>>> 928: fp_pw_thread_loop_unlock(pw.loop);
>>> 929: releaseToken(env, jtoken, token);
>>> 930: return RESULT_ERROR;
>>
>>
On Fri, 1 Dec 2023 13:09:52 GMT, Anton Bobrov wrote:
> hey, a fellow Sun comrade! (i still have my Sun badge too) :)
:handshake:
> I dont think modern compilers would do that
I would argue that no standard-compliant compiler would do that.
`volatile` is very hard to summarize without loosin
On Fri, 1 Dec 2023 11:21:59 GMT, Maxim Kartashev wrote:
>> This patch addresses the issues described in the
>> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
>> signalling around libpipewire thread loop condition variables and also
>> fixing libpipewire error dete
On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov wrote:
> This patch addresses the issues described in the
> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
> signalling around libpipewire thread loop condition variables and also fixing
> libpipewire error detection
On Thu, 30 Nov 2023 21:41:53 GMT, Alexander Zvegintsev
wrote:
>> This patch addresses the issues described in the
>> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
>> signalling around libpipewire thread loop condition variables and also
>> fixing libpipewire err
On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov wrote:
> This patch addresses the issues described in the
> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
> signalling around libpipewire thread loop condition variables and also fixing
> libpipewire error detection
On Thu, 30 Nov 2023 18:54:42 GMT, Phil Race wrote:
> It will test that it builds, but nothing more.
Right, thanks. Still useful it's not breaking a build :) Besides, the settings
carry forward for future PRs.
-
PR Comment: https://git.openjdk.org/jdk/pull/16794#issuecomment-183441
On Thu, 23 Nov 2023 13:21:10 GMT, Severin Gehwolf wrote:
> @antbob Please trigger a test run of GHA. You should be able to do that in
> https://github.com/antbob/jdk/actions/workflows/main.yml (manual trigger).
> Thanks!
That is pointless for this change. There are ZERO tests that GHA runs tha
On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov wrote:
> This patch addresses the issues described in the
> https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
> signalling around libpipewire thread loop condition variables and also fixing
> libpipewire error detection
This patch addresses the issues described in the
https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and
signalling around libpipewire thread loop condition variables and also fixing
libpipewire error detection and signalling and propagation to the screencast
API. This make
21 matches
Mail list logo