From: Pillum <dai...@gm...> - 2009-12-14 16:16:16
|
Hey guys, I started to program a platform independent networking library for windows and *nix systems and already implemented the entire *nix version of it. So far, so good. But the windows version is the thing that causes trouble....because the deprecated use of inet_addr I'll use inet_pton and inet_pton (despite the lack of it in Windows XP and earlier) to convert the format of IP adresses. Unfortunately, this functions are missing in the w32api package of MinGW (winsock2 to be exact). Maybe because its a new function, which is only implemented in NT 6 and later. So, I'm unable to use it and asking you when it is supported in MinGW and if it is going to be supported in MinGW at all in the next time (= next months)? thank you! -- View this message in context: http://n2.nabble.com/Win32API-request-for-new-functions-tp4165032p4165032.html Sent from the MinGW-users mailing list archive at Nabble.com. |
From: Chris S. <ir0...@gm...> - 2009-12-15 12:11:48
|
> Unfortunately, this functions are missing in the w32api package of MinGW > (winsock2 to be exact). Maybe because its a new function, which is only > implemented in NT 6 and later. > So, I'm unable to use it and asking you when it is supported in MinGW and if > it is going to be supported in MinGW at all in the next time (= next > months)? If you can supply a patch for w32api that implements the functions that you require using publicly available information, I will be more than happy to review it and possibly include it in the next w32api release. Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2009-12-15 19:06:41
|
On Monday 14 December 2009 16:16:06 Pillum wrote: > the windows version is the thing that causes trouble....because > the deprecated use of inet_addr Deprecated doesn't mean withdrawn, or unavailable; you'll still need to use inet_addr() on Windows, if you want to support users of older versions than Vista, (XP still has a strong following). Of course, for such users, you will only be able to support IPv4 addressing. > I'll use inet_pton and inet_pton I guess you meant to write inet_pton() and inet_ntop()? > (despite the lack of it in Windows XP and earlier) Hence, you will deny support for those who didn't follow the lemmings jumping to Vista or Windows-7. > to convert the format of IP adresses. > > Unfortunately, this functions are missing in the w32api package of > MinGW (winsock2 to be exact). Maybe because its a new function, > which is only implemented in NT 6 and later. More likely because no one has been sufficiently motivated yet, to add the necessary implementation. > So, I'm unable to use it and asking you when it is supported in > MinGW and if it is going to be supported in MinGW at all in the > next time (= next months)? They can be supported, (in CVS at least), just as soon as someone with the necessary motivation, (maybe you), provides a satisfactory patch to implement them; see: http://mingw.org/wiki/SubmitPatches Note that you *must* base your patch *exclusively* on pubicly accessible *documentation*, (such as available on MSDN); *never* examine the headers from any Microsoft SDK, nor from any other project which may have done so. A quick skim of the MSDN entries for InetPton() (== inet_pton()) and InetNtop() (== inet_ntop()) suggests that there is sufficient information available to permit development of a fully functional implementation. Once it gets into CVS, it will automatically be included in the next w32api release, (usually within six months of patch acceptance). -- Regards, Keith. |
From: Roger P. <rog...@gm...> - 2009-12-15 19:23:17
|
> They can be supported, (in CVS at least), just as soon as someone > with the necessary motivation, (maybe you), provides a satisfactory > patch to implement them; see: http://mingw.org/wiki/SubmitPatches CVS? Any chance for a git/github repository? -r |
From: Clive M. <Cli...@ms...> - 2009-12-16 03:40:28
|
You know I must be in trouble, otherwise why would I risk one of the humiliating comments that Keith usually makes to everyone? Nevertheless, is the MinGW rand_r(int *seed) thread safe? This reminds me of the scene in Marathon Man when Laurence Olivier asks Dustin Hoffman "Is it safe?" I don't need cryptography-grade numbers, but I'd like them to be different! Clive. |
From: Keith M. <kei...@us...> - 2009-12-16 08:28:22
|
On Wednesday 16 December 2009 03:40:09 Clive McCarthy wrote: > You know I must be in trouble, otherwise why would I risk one of > the humiliating comments that Keith usually makes to everyone? I don't make humiliating comments to everyone; only to those who blatantly refuse to follow the rules of ettiquette. Here, your question is 100% IRRELEVANT to the thread you've hijacked; it should not get a pertinent answer, until you repost it appropriately, in a new thread. -- Regards, Keith. |
From: Clive M. <Cli...@ms...> - 2009-12-16 15:42:24
|
-------------------------------------------------- From: "Keith Marshall" <kei...@us...> Sent: Wednesday, December 16, 2009 12:28 AM To: <min...@li...> Subject: Re: [Mingw-users] is MinGW rand_r() thread safe? > On Wednesday 16 December 2009 03:40:09 Clive McCarthy wrote: >> You know I must be in trouble, otherwise why would I risk one of >> the humiliating comments that Keith usually makes to everyone? > > I don't make humiliating comments to everyone; only to those who > blatantly refuse to follow the rules of ettiquette. Here, your > question is 100% IRRELEVANT to the thread you've hijacked; it should > not get a pertinent answer, until you repost it appropriately, in a > new thread. > > -- > > Regards, > Keith. QED. Clive. |
From: Roger P. <rog...@gm...> - 2009-12-16 17:31:41
|
> On Wednesday 16 December 2009 03:40:09 Clive McCarthy wrote: >> You know I must be in trouble, otherwise why would I risk one of >> the humiliating comments that Keith usually makes to everyone? > > I don't make humiliating comments to everyone; only to those who > blatantly refuse to follow the rules of ettiquette. Here, your > question is 100% IRRELEVANT to the thread you've hijacked; it should > not get a pertinent answer, until you repost it appropriately, in a > new thread. LOL. That was half in jest, right? -r |
From: Mathieu D. <der...@gm...> - 2009-12-16 18:48:36
|
POSIX introduced few times ago new libc functions suffixed with_r, probably meaning 'reentrant'. This was for fixing the problem of not thread-safe POSIX functions. _r functions are the same than the previous, except they are thread safe by definition. So yes this rand_r() func is thread-safe. Hope I've been usefull. 2009/12/16 Clive McCarthy <Cli...@ms...> > You know I must be in trouble, otherwise why would I risk one of the > humiliating comments that Keith usually makes to everyone? > > Nevertheless, is the MinGW rand_r(int *seed) thread safe? > This reminds me of the scene in Marathon Man when Laurence Olivier asks > Dustin Hoffman "Is it safe?" > > I don't need cryptography-grade numbers, but I'd like them to be different! > > Clive. > > > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- Dupuy Mathieu Epitech 2011. |
From: Tor L. <tm...@ik...> - 2009-12-16 19:45:27
|
But to get back to the original poster's question, as far as I can see there isn't any rand_r() "in MinGW" . I don't know what he meant exactly by thread-safe, though... That each thread has a separate state and separately seedable sequence of random numbers (and thus threads that use the same seed, perhaps the implicit one if no srand() is called, get the same sequence)? Or that they share state (in a thread-safe manner, protected by lock if not atomically updated) and thus even if srand() is not called the sequence is different in each thread? Either of the above interpretation can justifiablty be said to be "thread-safe" imho. Or something slightly different? Anyway, the srand() and rand() functions in msvcrt.dll (which is the C library that MinGW-built code uses) seem to use per-thread state that is separately seeded, i.e. any srand() call in the "main" thread before another thread is started doesn't affect the seed used in the thread. Try the following test program: #include <stdio.h> #include <stdlib.h> #include <math.h> #include <process.h> #define _WIN32_WINNT 0x0500 #include <windows.h> static unsigned __stdcall doit (void *data) { int i; volatile int k; int *ip = data; /* Let each thread run for a significant time so that we are more * likely to get overlapped execution. */ for (i = 0; i < 100000000; i++) k = rand (); for (i = 0; i < ip[0]; i++) ip[i+1] = rand (); return 0; } int main (int argc, char **argv) { int *ia0, **ia; HANDLE *handles; int i, j; int seed; int nnums; int nthreads; if (argc != 4) { fprintf (stderr, "Usage: %s seed nnums nhreads\n" " seed is the srand() seed to use in main(), use zero for no explicit seed\n" " nnums is the number of rand() calls\n" " nthreads is the number of threads to use\n", argv[0]); exit (1); } seed = atoi (argv[1]); nnums = atoi (argv[2]); nthreads = atoi (argv[3]); ia0 = malloc ((nnums + 1) * sizeof(int)); ia0[0] = nnums; if (seed != 0) srand (seed); doit (ia0); ia = malloc (nthreads * sizeof (int *)); handles = malloc (nthreads * sizeof (HANDLE)); /* Start n threads */ for (j = 0; j < nthreads; j++) { unsigned tid; ia[j] = malloc ((nnums + 1) * sizeof (int)); ia[j][0] = nnums; _beginthreadex (NULL, 0, doit, ia[j], 0, &tid); handles[j] = OpenThread (SYNCHRONIZE, FALSE, tid); } printf ("In main thread:\n"); for (i = 0; i < nnums; i++) printf ("%8d\n", ia0[i+1]); /* Wait for the threads to finish */ for (j = 0; j < nthreads; j++) WaitForSingleObject (handles[j], INFINITE); for (j = 0; j < nthreads; j++) { printf ("Thread %d:\n", j); for (i = 0; i < nnums; i++) printf ("%8d\n", ia[j][i+1]); } return 0; } |