We don't grab stream_cs to change any variables checked here, except to reset
flush_event, and that cannot result in a deadlock.
The only possible deadlocks here are:
(1) between this function and EndOfStream(), which is correct, as the two
should presumably be serialized;
(2) between this function and EndFlush(); however, in that case we expect
BeginFlush() first, which will unblock the streaming thread.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't grab stream_cs to change any variables checked here, except to reset
flush_event, and that cannot result in a deadlock.
The only possible deadlocks here are:
(1) between this function and EndOfStream(), which is correct, as the two
should presumably be serialized;
(2) between this function and EndFlush(); however, in that case we expect
BeginFlush() first, which will unblock the streaming thread.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't grab stream_cs to change any variables checked here, except to reset
flush_event, and that cannot result in a deadlock.
The only possible deadlocks here are:
(1) between this function and EndOfStream(), which is correct, as the two
should presumably be serialized;
(2) between this function and EndFlush(); however, in that case we expect
BeginFlush() first, which will unblock the streaming thread.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't grab stream_cs to change any variables checked here, except to reset
flush_event, and that cannot result in a deadlock.
The only possible deadlocks here are:
(1) between this function and Receive(), which is correct, as the two
should presumably be serialized;
(2) between this function and EndFlush(); however, in that case we expect
BeginFlush() first, which will unblock the streaming thread.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Have the winebuild -spec.o include an undefined .globl referencing
symbols we know the winecrt0 entry point will eventually reference,
so ld knows about that need while scanning library archives.
Signed-off-by: Kevin Puetz <PuetzKevinA@JohnDeere.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Override --entry in winegcc only when it applies to any compiler
(e.g. kernel drivers or msvcrt) but leave spec details to winebuild.
Forward -municode so winebuild will know which to use.
Signed-off-by: Kevin Puetz <PuetzKevinA@JohnDeere.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Checking for the _rtld_version_laddr_offset symbol only works when
header and library versions match. Checking for the offset of l_addr
instead lets us use the older header with the new library too.
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It could sometimes be NULL, such as win32k.sys on Win <= 7.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Service display names are often translated.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Analogous to the Vulkan adapter. This is slightly awkward in OpenGL
because it doesn't have explicit command buffers like Vulkan, but
calling wined3d_context_gl_submit_command_fence() on swapchain present
works well enough in practice. The main advantage of this approach is that it
avoids using a separate fence for each usage of each bo.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard