[HACKERS] Win32 port - current status?
Hi all, just wondering if the guys involved in the Win32 port could give a quick update? I'm just (one of the many?) hanging out for this, to justify continued use of Postgres to the powers that be. Seems like there has been no word on this for a couple weeks, and I'm not even sure whether or not it has made/will make it into 7.4? Perhaps I've missed a crucial message somewhere... All the best, Claudio Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Win32 for 7.5... how to help?
Hi all, This probably more than a little premature/ill-timed, but I was hoping to start a groundswell of support for Win32 port. I, and I imagine quite a number of capable lurkers on the list, would love to get involved. Is there a way that work can be doled out now/soon, so that we can make the next release (and with more stability than we might have expected had the port squeezed into 7.4). How do we help? No doubt this'll be shelved until some time after 7.4 is pushed out, but it would be great if one of the Postgres "heavies" (figuratively :-) would pro-actively lead this... Best of all, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Win32 for 7.5... how to help?
> I am already leading it, I think. Ok. How do the willing get involved? Cheers, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Win32 for 7.5... how to help?
> Uh, the two big items are Win32 signal code, and reordering > the startup code to allow exec without fork. Both are pretty > complicated, but I do ask for assistance on the hackers list. Ok. I guess we'll just keep our eyes peeled for the next time we can help out. Thanks for the replies... --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL for windows)
Tom Lane writes: > BTW, I've been wondering lately if we'd not be better off to look at > using threading in the Windows port, if it'd help us get around the > fork/exec data transfer problem. I'm not sure that it would, > mind you, but if it would give an answer it might be a lot less painful than > solving the data transfer problem directly. Some coincidence. Was just about to post a message to the hackers-win32 list, asking if anyone was considering using threads for the Windows port, and why/if sub-processes were the preferred option (from the TODO items on http://momjian.postgresql.org/main/writings/pgsql/win32.html mention CreateProcess). Having looked at the code for the first time over the past day and a half, I'm quite sure that using threads is the easier option (and, generally, replacing fork/exec with winthreads is easier than using CreateProcess). FWIW, I've got a threaded version of the WIN32_DEV branch more or less "running" (it is a terrible hack job, so NO, no patches... yet :-), as a proof of concept. Still a work in progress (ok, I've qualified it enough), but it is showing enough promise to convince me that threading is the way to go for the Win32 port. Anyone else experienced with the code base care to weigh in on this? Cheers, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL for window
> Claudio Natoli <[EMAIL PROTECTED]> writes: > > FWIW, I've got a threaded version of the WIN32_DEV branch more or less > > "running" (it is a terrible hack job, so NO, no patches... yet :-), as a > > proof of concept. Still a work in progress (ok, I've qualified it enough), > > but it is showing enough promise to convince me that threading is the way to > > go for the Win32 port. > > How are you dealing with the issue of wanting some static variables to > be per-thread and others not? > > regards, tom lane To be perfectly honest, I'm still trying to familiarize myself with the code sufficiently well so that I can tell which variables need to be per-thread and which are shared (and, in turn, which of these need to be protected from concurrent access). So, in short, I'm not dealing with the issue (and, hence, it is only "running" in the very loosest sense of the word). Unfortunately, I'm not yet even in a position to propose a reasonable model, let alone one that'd play well with the existing code base. Perhaps some time soon, hopefully... (I really want to get involved in this.) Cheers, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Threads vs Processes
> Another option would be to create thread local hashtable or other lookup > structure to which you would register a structure for a particular .c > file or group of files. > > You could then define the structures you need locally without > affecting other parts of the codebase. > > > > Myron Scott A slight variant on this idea would be to mask the variables themselves, using macrology on a hash keyed on the threadID. To illustrate: MyProc->errType would, on a threaded system, become something like: ((PGProc*)ThreadLocalHash(MyProc,GetCurrentThreadID()))->errType I'm imagining that an approach like this would fit in very nicely with the existing code. Not the most performance friendly solution however (and I'm guessing that there might be a place or two where this might be important :-). Just a thought, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
