Re: [Libusbx-devel] Releasing 1.0.16 ...
Hi, On 07/12/2013 12:15 AM, Pete Batard wrote: > freecode has now been updated (but each new entry gets reviewed by the > freecode people before it is published, so it may be a few hours before it > gets publicized) along with the index page on http://libusbx.org (there is a > link to the latest Windows binaries, that has to be updated for each release, > and I also added a small blurb about the improvement of the libusb situation > and the plan to merge back). > Thank! > I'll just remind everyone that if you have write access to the libusbx github > repo, then you can update the index page by using the libusbx.github.com git > project [1]. > > Finally, the default download from SF was set to the windows binaries, which > is not what we want, especially as we always use the default SF download for > the latest source on the index page. > > Since a picture is worth a thousand words, Indeed :) I'll try to remember to set those checkboxes the next time. Thanks for pointing this out and fixing it. Regards, Hans -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Releasing 1.0.16 ...
On Fri, Jul 12, 2013 at 3:14 PM, Hans de Goede wrote: > On 07/12/2013 12:15 AM, Pete Batard wrote: >> Finally, the default download from SF was set to the windows binaries, >> which is not what we want, especially as we always use the default SF >> download for the latest source on the index page. >> >> Since a picture is worth a thousand words, > > Indeed :) I'll try to remember to set those checkboxes the next time. > Thanks for pointing this out and fixing it. Actually I have a slightly different opinion, looking at other projects, I think a more suitable way is like the following. For Windows, the default is set to the Windows binary. For other OS, the default is the source tar ball. Windows CE may be an exception and it is probably not in the list of OS choices. The reason to set the default for Windows platform as the Windows binary is that in reality most of the Windows user will probably use the binary and not the tar ball. -- Xiaofan -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] [PATCH] Windows: Fix race between windows_clock_gettime_threaded() and windows_clock_gettime()
When the timer thread is created in windows_init(), it performs an
initialisation phase in which it uses QueryPerformanceFrequency() to determine
if there is a high resolution timer available, and sets hires_frequency and
hires_ticks_to_ps appropriately. However, since windows_init() does not wait for
this initialisation phase to complete, windows_clock_gettime() can be called
before hires_frequency and hires_ticks_to_ps have been updated. This can result
in windows_clock_gettime() temporarily returning real-time clock values even
though the platform supports a monotonic clock.
This patch addresses this issue by having windows_init() wait until the timer
thread has initialised before returning.
Signed-off-by: Simon Haggett
---
libusb/os/windows_usb.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index 63357b1..097029c 100644
--- a/libusb/os/windows_usb.c
+++ b/libusb/os/windows_usb.c
@@ -886,6 +886,12 @@ static int windows_init(struct libusb_context *ctx)
}
SetThreadAffinityMask(timer_thread, 0);
+ // Wait for timer thread to init before continuing.
+ if (WaitForSingleObject(timer_response, INFINITE) !=
WAIT_OBJECT_0) {
+ usbi_err(ctx, "Failed to wait for timer thread to
become ready - aborting");
+ goto init_exit;
+ }
+
// Create a hash table to store session ids. Second parameter
is better if prime
htab_create(ctx, HTAB_SIZE);
}
@@ -2172,6 +2178,11 @@ unsigned __stdcall windows_clock_gettime_threaded(void*
param)
usbi_dbg("hires timer available (Frequency: %"PRIu64" Hz)",
hires_frequency);
}
+ // Signal windows_init() that we're ready to service requests
+ if (ReleaseSemaphore(timer_response, 1, NULL) == 0) {
+ usbi_dbg("unable to release timer semaphore: %s",
windows_error_str(0));
+ }
+
// Main loop - wait for requests
while (1) {
timer_index = WaitForMultipleObjects(2, timer_request, FALSE,
INFINITE) - WAIT_OBJECT_0;
@@ -2206,7 +2217,7 @@ unsigned __stdcall windows_clock_gettime_threaded(void*
param)
nb_responses =
InterlockedExchange((LONG*)&request_count[0], 0);
if ( (nb_responses)
&& (ReleaseSemaphore(timer_response, nb_responses,
NULL) == 0) ) {
- usbi_dbg("unable to release timer semaphore %d:
%s", windows_error_str(0));
+ usbi_dbg("unable to release timer semaphore:
%s", windows_error_str(0));
}
continue;
case 1: // time to quit
--
1.7.9.5
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] [PATCH] WinCE: Fix race between wince_clock_gettime_threaded() and wince_clock_gettime()
When the timer thread is created in wince_init(), it performs an initialisation
phase in which it uses QueryPerformanceFrequency() to determine if there is a
high resolution timer available, and sets hires_frequency and hires_ticks_to_ps
appropriately. However, since wince_init() does not wait for this initialisation
phase to complete, wince_clock_gettime() can be called before hires_frequency
and hires_ticks_to_ps have been updated. This can result in
wince_clock_gettime() temporarily returning real-time clock values even though
the platform supports a monotonic clock.
This patch addresses this issue by having wince_init() wait until the timer
thread has initialised before returning.
Signed-off-by: Simon Haggett
---
libusb/os/wince_usb.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libusb/os/wince_usb.c b/libusb/os/wince_usb.c
index e4a6633..90c129b 100644
--- a/libusb/os/wince_usb.c
+++ b/libusb/os/wince_usb.c
@@ -234,6 +234,12 @@ static int wince_init(struct libusb_context *ctx)
usbi_err(ctx, "Unable to create timer thread -
aborting");
goto init_exit;
}
+
+ // Wait for timer thread to init before continuing.
+ if (WaitForSingleObject(timer_response, INFINITE) !=
WAIT_OBJECT_0) {
+ usbi_err(ctx, "Failed to wait for timer thread to
become ready - aborting");
+ goto init_exit;
+ }
}
// At this stage, either we went through full init successfully, or
didn't need to
r = LIBUSB_SUCCESS;
@@ -877,6 +883,11 @@ unsigned __stdcall wince_clock_gettime_threaded(void*
param)
usbi_dbg("hires timer available (Frequency: %"PRIu64" Hz)",
hires_frequency);
}
+ // Signal wince_init() that we're ready to service requests
+ if (ReleaseSemaphore(timer_response, 1, NULL) == 0) {
+ usbi_dbg("unable to release timer semaphore: %s",
windows_error_str(0));
+ }
+
// Main loop - wait for requests
while (1) {
timer_index = WaitForMultipleObjects(2, timer_request, FALSE,
INFINITE) - WAIT_OBJECT_0;
@@ -911,7 +922,7 @@ unsigned __stdcall wince_clock_gettime_threaded(void* param)
nb_responses =
InterlockedExchange((LONG*)&request_count[0], 0);
if ( (nb_responses)
&& (ReleaseSemaphore(timer_response, nb_responses,
NULL) == 0) ) {
- usbi_dbg("unable to release timer semaphore %d:
%s", windows_error_str(0));
+ usbi_dbg("unable to release timer semaphore:
%s", windows_error_str(0));
}
continue;
case 1: // time to quit
--
1.7.9.5
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Releasing 1.0.16 ...
On 11/07/13 23:15, Pete Batard wrote: > (but I'm still not too sure why -win became the default download and > not wince, which was uploaded later). The reason for this is probably because I've been uploading the wince binaries via SFTP. I've being doing it via SFTP because I don't get the sourceforge web UI with the add file and add folder buttons. Regards, TOby -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] [PATCH] hotplug: Pass explicit context to callbacks
Instead of passing NULL for the context to hotplug callbacks, if the context happens to be the default context, always pass the explicit context pointer. --- libusb/hotplug.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libusb/hotplug.c b/libusb/hotplug.c index 6b04342..36a8f05 100644 --- a/libusb/hotplug.c +++ b/libusb/hotplug.c @@ -167,8 +167,7 @@ static int usbi_hotplug_match_cb (struct libusb_context *ctx, return 0; } - return hotplug_cb->cb (ctx == usbi_default_context ? NULL : ctx, - dev, event, hotplug_cb->user_data); + return hotplug_cb->cb (ctx, dev, event, hotplug_cb->user_data); } void usbi_hotplug_match(struct libusb_context *ctx, struct libusb_device *dev, -- 1.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] [PATCH] hotplug: Pass explicit context to callbacks
The accompanying patch changes the hotplug callback invocation to always pass the explicit context pointer. The current behavior doesn't permit comparing contexts in the callback, when dealing with multiple contexts, as the comparison will fail, if the context is also the default and therefore NULL. Please CC me for any feedback, as I'm not subscribed to the list. Florian Albrechtskirchinger (1): hotplug: Pass explicit context to callbacks libusb/hotplug.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 1.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
