Re: Threading question .. am I doing this right?

Chris Angelico wrote: > I'm still curious as to the workload (requests per second), as it might still > be worth going for the feeder model. But if your current system works, then > it may be simplest to debug that rather than change. It is by all accounts a low-traffic situation, maybe one reques

Re: Threading question .. am I doing this right?

On Sat, 26 Feb 2022 at 05:16, Robert Latest via Python-list wrote: > > Chris Angelico wrote: > > Depending on your database, this might be counter-productive. A > > PostgreSQL database running on localhost, for instance, has its own > > caching, and data transfers between two apps running on the s

Re: Threading question .. am I doing this right?

Greg Ewing wrote: > * If more than one thread calls get_data() during the initial > cache filling, it looks like only one of them will wait for > the thread -- the others will skip waiting altogether and > immediately return None. Right. But that needs to be dealt with somehow. No data is no data.

Re: Threading question .. am I doing this right?

Chris Angelico wrote: > Depending on your database, this might be counter-productive. A > PostgreSQL database running on localhost, for instance, has its own > caching, and data transfers between two apps running on the same > computer can be pretty fast. The complexity you add in order to do > you

Re: Threading question .. am I doing this right?

On 25/02/22 1:08 am, Robert Latest wrote: My question is: Is this a solid approach? Am I forgetting something? I can see a few of problems: * If more than one thread calls get_data() during the initial cache filling, it looks like only one of them will wait for the thread -- the others will sk

Re: Threading question .. am I doing this right?

On Fri, 25 Feb 2022 at 06:54, Robert Latest via Python-list wrote: > > I have a multi-threaded application (a web service) where several threads need > data from an external database. That data is quite a lot, but it is almost > always the same. Between incoming requests, timestamped records get a

Re: threading and multiprocessing deadlock

Johannes Bauer wrote at 2021-12-6 00:50 +0100: >I'm a bit confused. In my scenario I a mixing threading with >multiprocessing. Threading by itself would be nice, but for GIL reasons >I need both, unfortunately. I've encountered a weird situation in which >multiprocessing Process()es which are start

Re: threading and multiprocessing deadlock

> On 5 Dec 2021, at 23:50, Johannes Bauer wrote: > > Hi there, > > I'm a bit confused. In my scenario I a mixing threading with > multiprocessing. Threading by itself would be nice, but for GIL reasons > I need both, unfortunately. I've encountered a weird situation in which > multiprocessing

Re: threading and multiprocessing deadlock

Am 06.12.21 um 13:56 schrieb Martin Di Paola: > Hi!, in short your code should work. > > I think that the join-joined problem is just an interpretation problem. > > In pseudo code the background_thread function does: > > def background_thread() >   # bla >   print("join?") >   # bla >   print("j

Re: threading and multiprocessing deadlock

Hi!, in short your code should work. I think that the join-joined problem is just an interpretation problem. In pseudo code the background_thread function does: def background_thread() # bla print("join?") # bla print("joined") When running this function in parallel using threads, you

Re: Threading plus multiprocessing plus cv2 error

On Sat, Aug 29, 2020 at 06:24:10PM +1000, John O'Hagan wrote: > Dear list > > Thanks to this list, I haven't needed to ask a question for > a very long time, but this one has me stumped. > > Here's the minimal 3.8 code, on Debian testing: > > - > from multiprocessing import Process > from th

Re: Threading plus multiprocessing plus cv2 error

On Sun, 30 Aug 2020 09:59:15 +0100 Barry Scott wrote: > > > > On 29 Aug 2020, at 18:01, Dennis Lee Bieber > > wrote: > > > > On Sat, 29 Aug 2020 18:24:10 +1000, John O'Hagan > > declaimed the following: > > > >> There's no error without the sleep(1), nor if the Process is > >> started befor

Re: Threading plus multiprocessing plus cv2 error

On 2020-08-30, Barry wrote: >* The child process is created with a single thread—the one that > called fork(). The entire virtual address space of the parent is > replicated in the child, including the states of mutexes, > condition variables, and other pthr

Re: Threading plus multiprocessing plus cv2 error

> On 30 Aug 2020, at 11:03, Stephane Tougard via Python-list > wrote: > > On 2020-08-30, Chris Angelico wrote: >>> I'm not even that makes sense, how 2 processes can share a thread ? >>> >> They can't. However, they can share a Thread object, which is the >> Python representation of a threa

Re: Threading plus multiprocessing plus cv2 error

On 2020-08-30, Chris Angelico wrote: >> I'm not even that makes sense, how 2 processes can share a thread ? >> > They can't. However, they can share a Thread object, which is the > Python representation of a thread. That can lead to confusion, and > possibly the OP's error (I don't know for sure,

Re: Threading plus multiprocessing plus cv2 error

> On 29 Aug 2020, at 18:01, Dennis Lee Bieber wrote: > > On Sat, 29 Aug 2020 18:24:10 +1000, John O'Hagan > declaimed the following: > >> There's no error without the sleep(1), nor if the Process is started >> before the Thread, nor if two Processes are used instead, nor if two >> Threads ar

Re: Threading plus multiprocessing plus cv2 error

On Sat, 29 Aug 2020 13:01:12 -0400 Dennis Lee Bieber wrote: > On Sat, 29 Aug 2020 18:24:10 +1000, John O'Hagan > declaimed the following: > > >There's no error without the sleep(1), nor if the Process is started > >before the Thread, nor if two Processes are used instead, nor if two > >Threads

Re: Threading plus multiprocessing plus cv2 error

> On Aug 29, 2020, at 10:12 PM, Stephane Tougard via Python-list > wrote: > > On 2020-08-29, Dennis Lee Bieber wrote: >> Under Linux, multiprocessing creates processes using fork(). That means >> that, for some fraction of time, you have TWO processes sharing the same >> thread and all t

Re: Threading plus multiprocessing plus cv2 error

On Sun, Aug 30, 2020 at 4:01 PM Stephane Tougard via Python-list wrote: > > On 2020-08-29, Dennis Lee Bieber wrote: > > Under Linux, multiprocessing creates processes using fork(). That > > means > > that, for some fraction of time, you have TWO processes sharing the same > > thread and al

Re: Threading plus multiprocessing plus cv2 error

On 2020-08-29, Dennis Lee Bieber wrote: > Under Linux, multiprocessing creates processes using fork(). That means > that, for some fraction of time, you have TWO processes sharing the same > thread and all that entails (if it doesn't overlay the forked process with > a new executable, they a

Re: Threading module and embedded python

Thank you for your help. I made a minimum example which just creates the dialog window. This runs, using the standard python37.exe without a problem. But this also runs within the embedded interpreter slightly different then my previous code. In my previous code I used the hwnd from the C++ app

Re: Threading module and embedded python

> On 16 Apr 2020, at 14:55, Eko palypse wrote: > > Barry, sorry for sending you a private message yesterday, was not intended. > > No, I only have rudimentary knowledge of C++, > but it has been developing since I started using Cython. > I haven't done any stack analysis yet but hey, there's a

Re: Threading module and embedded python

Barry, sorry for sending you a private message yesterday, was not intended. No, I only have rudimentary knowledge of C++, but it has been developing since I started using Cython. I haven't done any stack analysis yet but hey, there's always a first time. I think my stubbornness could be of help he

Re: Threading module and embedded python

> On 15 Apr 2020, at 21:18, Eko palypse wrote: > > Thank you for your suggestion. I will give it a try. > >> What is the "stuck" thread doing? waiting for a lock? > > No, it should open a dialog created with DialogBoxIndirectParamW >

Re: Threading module and embedded python

Thank you for your suggestion. I will give it a try. > What is the "stuck" thread doing? waiting for a lock? No, it should open a dialog created with DialogBoxIndirectParamW . Eren Am Mi., 15. Apr. 2

Re: Threading module and embedded python

> On 15 Apr 2020, at 13:30, Eko palypse wrote: > > Hi everyone, > > the following happens on Windows7 x64 and Python37 x64 > > I have a plugin DLL for a C++ application in which Python37 is embedded. > The plugin itself works, except when I want to use the threading module. > > If I start a

Re: Threading

On 24Jan2020 21:08, Dennis Lee Bieber wrote: My suggestion for your capacity thing: use a Semaphore, which is a special thread safe counter which cannot go below zero. from threading import Semaphore def start_test(sem, args...): sem.acquire() ... do stuff with args ...

Re: Threading

> Not quite. > > 1. Create a list of threads. > > 2. Put the items into a _queue_, not a list. > > 3. Start the threads. > > 4. Iterate over the list of threads, using .join() on each. > > If you're going to start the threads before you've put all of the items > into the queue, you can also put a

Re: Threading

First come remarks, then a different suggestion about your capacity problem (no more than 10). Details below. On 24Jan2020 16:03, Matt wrote: Created this example and it runs. [...] big_list = [] for i in range(1, 200): big_list.append(i) You can just go: big_list.extend(range(1,200

Re: Threading

On Sat, Jan 25, 2020 at 9:05 AM Matt wrote: > > Created this example and it runs. > > import time > import threading > > big_list = [] > > for i in range(1, 200): > big_list.append(i) > > def start_test(): > while big_list: #is this > list_item = big_list.pop() #and this thread

Re: Threading

Created this example and it runs. import time import threading big_list = [] for i in range(1, 200): big_list.append(i) def start_test(): while big_list: #is this list_item = big_list.pop() #and this thread safe print list_item, port time.sleep(1) print

Re: Threading

On 2020-01-24 21:33, Matt wrote: So I would create 10 threads. And each would pop items off list like so? def start_test(): while big_list: list_item = big_list.pop() print list_item, port sleep(1) port = 80 for i = 1 to 10 t = Thread(target=start_test)

Re: Threading

So I would create 10 threads. And each would pop items off list like so? def start_test(): while big_list: list_item = big_list.pop() print list_item, port sleep(1) port = 80 for i = 1 to 10 t = Thread(target=start_test) t.start() t.join() Would that be t

Re: Threading

On Sat, 25 Jan 2020 07:43:49 +1100 Chris Angelico wrote: > On Sat, Jan 25, 2020 at 7:35 AM Matt wrote: > > > > I am using this example for threading in Python: > > > > from threading import Thread > > > > def start_test( address, port ): > > print address, port > > sleep(1) > > > > for l

Re: Threading

On Sat, Jan 25, 2020 at 7:35 AM Matt wrote: > > I am using this example for threading in Python: > > from threading import Thread > > def start_test( address, port ): > print address, port > sleep(1) > > for line in big_list: > t = Thread(target=start_test, args=(line, 80)) > t.sta

RE: threading

100 increments happen very fast, and means each thread will probably complete before the main thread has even started the next one. Bump that up to 1_000_000 or so and you'll probably trigger it. I did a test with a print(x) at the start of test() to see what the number was when each thread kic

Re: Threading Keyboard Interrupt issue

On 5/29/19, Dennis Lee Bieber wrote: > > In the OP's example code, with just one thread started, the easiest > solution is to use > > y.start() > y.join() > > to block the main thread. That will, at least, let the try/except catch the > interrupt. It does not, however, kill the s

Re: Threading Keyboard Interrupt issue

On 5/29/19, David Raymond wrote: > > Keyboard interrupts are only received by the main thread, which in this case > completes real quick. > > So what happens for me is that the main thread runs to completion instantly > and leaves nothing alive to receive the keyboard interrupt, which means the >

RE: Threading Keyboard Interrupt issue

That's a little weird, and my running it works slightly differently. Please paste exactly what you're running (no time import and true being lowercase for example means we couldn't copy and paste it and have it immediately run) In your script, the main thread hits y.start() which completes succe

Re: Threading Keyboard Interrupt issue

On Thu, May 30, 2019 at 1:45 AM nihar Modi wrote: > > I have written a simple code that involves threading, but it does not go to > except clause after Keyboard interrupt. Can you suggest a way out. I have > pasted the code below. It does not print 'hi' after keyboard interrupt and > just stops.

Re: Threading is foobared?

Mark Sapiro wrote: > Random832 wrote: > >> Any chance that it could fix reference headers to match? >> >> Actually, merely prepending the original Message-ID itself to the >> references header might be enough to change the reply's situation from >> "nephew" ("reply to [missing] sibling") to "gran

Re: Threading is foobared?

Random832 wrote: > One additional thing that would be nice and would solve most of the > duplicate problem with hypothetically including the rewritten > Message-IDs in outgoing emails, would be to detect crossposts to > multiple lists in the same Mailman instance, and to send them to Usenet > (and

Re: Threading is foobared?

Random832 wrote: > Any chance that it could fix reference headers to match? > > Actually, merely prepending the original Message-ID itself to the > references header might be enough to change the reply's situation from > "nephew" ("reply to [missing] sibling") to "grandchild" ("reply to > [missin

Re: Threading is foobared?

On Thursday 31 March 2016 15:50, Mark Sapiro wrote: > Hi all, > > I'm jumping in on this thread because Tim asked. [...] Thanks for the explanation! -- Steve -- https://mail.python.org/mailman/listinfo/python-list

Re: Threading is foobared?

On Thu, Mar 31, 2016, at 01:25, Random832 wrote: > Actually, merely prepending the original Message-ID itself append, not prepend... I'd misremembered the order that References go in. -- https://mail.python.org/mailman/listinfo/python-list

Re: Threading is foobared?

On Thu, Mar 31, 2016, at 01:25, Random832 wrote: > > if a message is cross-posted to two lists which both gateway to Usenet, > > and Mailman didn't make the Message-IDs unique, the news server would > > discard one of the two posts as a duplicate and the post would be > > missing from one of the re

Re: Threading is foobared?

On Thu, Mar 31, 2016, at 00:50, Mark Sapiro wrote: > What Mailman does do as noted by Random832 is replace the Message-ID: > header value in posts gated to Usenet with a list specific, Mailman > generated unique value. There is a reason for this, and that reason is > if a message is cross-posted to

Re: Threading is foobared?

Hi all, I'm jumping in on this thread because Tim asked. I'm here because I'm a Mailman developer and the primary maintainer of Mailman for the @python.org lists. Regarding the initial post in this thread from Steven D'Aprano suggesting that broken threading is more common recently and quoting a

Re: Threading is foobared?

On 30.03.2016 01:43, Steven D'Aprano wrote: On Tue, 29 Mar 2016 09:26 pm, Sven R. Kunze wrote: On 27.03.2016 05:01, Steven D'Aprano wrote: Am I the only one who has noticed that threading of posts here is severely broken? It's always been the case that there have been a few posts here and ther

Re: Threading is foobared?

On Tue, Mar 29, 2016, at 19:54, Rob Gaddi wrote: > Just read on Usenet instead of through the mailing list. That way > you can accept broken threading as a given rather than wonder why it's > happening in a particular case. It's a given everywhere. Any thread that contains a sufficient number of

Re: Threading is foobared?

Steven D'Aprano wrote: > Am I the only one who has noticed that threading of posts here is severely > broken? It's always been the case that there have been a few posts here and > there that break threading, but now it seems to be much more common. > > For instance, I see Jerry Martens' post "help

Re: Threading is foobared?

On Tue, 29 Mar 2016 09:26 pm, Sven R. Kunze wrote: > On 27.03.2016 05:01, Steven D'Aprano wrote: >> Am I the only one who has noticed that threading of posts here is >> severely broken? It's always been the case that there have been a few >> posts here and there that break threading, but now it se

Re: Threading is foobared?

On 27.03.2016 05:01, Steven D'Aprano wrote: Am I the only one who has noticed that threading of posts here is severely broken? It's always been the case that there have been a few posts here and there that break threading, but now it seems to be much more common. I agree. Didn't we both already

Re: Threading is foobared?

On 27/03/2016 07:25, Random832 wrote: On Sat, Mar 26, 2016, at 23:18, Ben Finney wrote: What you've demonstrated is that at least one host is violating communication standards by altering existing reference fields on messages in transit. The usenet gateway relays posts that originated on the m

Re: Threading is foobared?

On Sat, Mar 26, 2016, at 23:18, Ben Finney wrote: > What you've demonstrated is that at least one host is violating > communication standards by altering existing reference fields on > messages in transit. The usenet gateway relays posts that originated on the mailing list to usenet with their *Me

Re: Threading is foobared?

Steven D'Aprano writes: > Am I the only one who has noticed that threading of posts here is > severely broken? It's always been the case that there have been a few > posts here and there that break threading, but now it seems to be much > more common. I can't give an objective assessment of whet

Re: threading bug in strptime

Larry Martell writes: > We have been trying to figure out an intermittent problem where a > thread would fail with this: > > AttributeError: 'module' object has no attribute '_strptime' > > Even though we were importing datetime. After much banging our heads > against the wall, we found this: > >

Re: Threading: execute a callback function in the parent thread

On Fri, Mar 20, 2015 at 11:29 AM, wrote: > Hi everyone, > > just like the title says I'm searching for a mechanism which allows to call a > callback function from a thread, being the callback executed in the parent > thread (it can also be the main thread). I'm basically looking for something

Re: Threading in Python, Please check the script

On Tuesday, January 13, 2015 at 10:22:32 PM UTC-8, Robert Clove wrote: > Hi All, > > I have made a script in which i have started two thread named thread 1 and > thread 2. > In thread 1 one function will run named func1 and in thread 2 function 2 will > run named func 2. > Thread 1 will execute

Re: Threading in Python, Please check the script

On 01/14/2015 07:11 AM, Robert Clove wrote: Can u provide me the pseudo script. You say you're a beginner. If so, you shouldn't be trying to use threads, which are tricky. I've been programming for 46 years, and I seldom have had to write multi-threading code. But this looks like a school

Re: Threading in Python, Please check the script

Can u provide me the pseudo script. On Wed, Jan 14, 2015 at 4:10 PM, Dave Angel wrote: > On 01/14/2015 01:22 AM, Robert Clove wrote: > >> Hi All, >> >> > In any new thread, you should specify what versions of Python and OS > you're using. I'll assume Python 2.7 and Linux for this message. > >

Re: Threading in Python, Please check the script

On 01/14/2015 01:22 AM, Robert Clove wrote: Hi All, In any new thread, you should specify what versions of Python and OS you're using. I'll assume Python 2.7 and Linux for this message. I have made a script in which i have started two thread named thread 1 and thread 2. In thread 1 one fu

Re: threading

Rustom Mody : > Half-assed support in current languages does not imply any necessary > problem in the idea -- just in the mainstream implementations of it. > > Then looking it up I find Go's goroutines have the same issue. the promise of threads is that you only need to consider a single event ou

Re: threading

On Friday, April 11, 2014 9:06:47 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody: > > On Friday, April 11, 2014 10:45:08 AM UTC+5:30, Rustom Mody wrote: > > >> On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote: > > >> > (1) oversimplification which makes it difficult to exten

Re: threading

On 2014-04-11, Roy Smith wrote: > At a high level, threads and coroutines are really very similar. They > are both independent execution paths in the same process. I guess the > only real difference between them is that thread switching is mediated > by the operating system, so it can happen

Re: threading

On 11/04/2014 16:53, Chris Angelico wrote: On Sat, Apr 12, 2014 at 1:36 AM, Marko Rauhamaa wrote: The simplest example: there's no general way to terminate a thread. Hacks exist for some occasions, but they can hardly be considered graceful. Having followed python-list for some time now, I ha

Re: threading

On Sat, Apr 12, 2014 at 1:36 AM, Marko Rauhamaa wrote: > The simplest example: there's no general way to terminate a thread. > Hacks exist for some occasions, but they can hardly be considered > graceful. Having followed python-list for some time now, I have to agree... you can't terminate a thre

Re: threading

Rustom Mody : > On Friday, April 11, 2014 10:45:08 AM UTC+5:30, Rustom Mody wrote: >> On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote: >> > (1) oversimplification which makes it difficult to extend the design >> > and handle all of the real-world contingencies >> >> This

Re: threading

In article <53477f29$0$29993$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > I think coroutines are awesome, but like all advanced concepts, sometimes > they can be abused, and sometimes they are hard to understand not because > they are hard to understand in and of themselves, b

Re: threading

Steven D'Aprano wrote: >> I have an issue with the use of coroutines. I think they are to evil. > > They are to evil ... as what? To evil as chalk is to cheese? Black is to > white? Bees are to honey? I think coroutines are one of those things that don't fit the human mind. A class with a co

Re: threading

On Friday, April 11, 2014 10:45:08 AM UTC+5:30, Rustom Mody wrote: > On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote: > > (1) oversimplification which makes it difficult to extend the design > > and handle all of the real-world contingencies > > This I dont... I meant "D

Re: threading

On Fri, 11 Apr 2014 01:51:41 +0200, Sturla Molden wrote: > On 10/04/14 21:44, Marko Rauhamaa wrote: >> I'm happy that asyncio is >> happening after all these long years. It would be nice if it supported >> edge-triggered wakeups, but I suppose that isn't supported in all >> operating systems. > >

Re: threading

On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody: > > > What you are saying is that what the OS is doing, you can do better. > > Analogous to said C programmer saying that what (data structures) the > > python programmer can make he can do better. > > > > I'm s

Re: threading

On 4/10/2014 7:51 PM, Sturla Molden wrote: On 10/04/14 21:44, Marko Rauhamaa wrote: I'm happy that asyncio is happening after all these long years. It would be nice if it supported edge-triggered wakeups, but I suppose that isn't supported in all operating systems. I have an issue with the use

Re: threading

On 11/04/14 01:51, Sturla Molden wrote: I have an issue with the use of coroutines. I think they are to evil. When a man like David Beazley says this https://twitter.com/dabeaz/status/440214755764994048 there is something crazy going on. And why did Python get this Tulip beast, instead

Re: threading

On 10/04/14 21:44, Marko Rauhamaa wrote: I'm happy that asyncio is happening after all these long years. It would be nice if it supported edge-triggered wakeups, but I suppose that isn't supported in all operating systems. I have an issue with the use of coroutines. I think they are to evil. W

Re: threading

Rustom Mody : > What you are saying is that what the OS is doing, you can do better. > Analogous to said C programmer saying that what (data structures) the > python programmer can make he can do better. I'm sorry, but I don't quite follow you there. I see the regular multithreaded approach as

Re: threading

On Friday, April 11, 2014 1:14:01 AM UTC+5:30, Marko Rauhamaa wrote: > > > Seriously, Erlang (and Go) have nice tools for managing state machines > and concurrency. However, Python (and C) are perfectly suitable for > clear asynchronous programming idioms. I'm happy that asyncio is > happening

Re: threading

Rustom Mody : > Marco (and evidently Chris) are in the CP camp whereas Sturla is in > the PP camp. Its just the 'data-structures (and algorithms)' is now > replaced by 'concurrency' > > Both these viewpoints assume that the status quo of current > (mainstream) language support for concurrency is a

Re: threading

On Thursday, April 10, 2014 10:38:49 PM UTC+5:30, Chris Angelico wrote: > On Fri, Apr 11, 2014 at 2:25 AM, Marko Rauhamaa wrote: > >> I don't know Python's asyncio as it's very new and I haven't yet found > >> an excuse to use it, but with Pike, I just engage backend mode, set > >> callbacks on the

Re: threading

On Fri, Apr 11, 2014 at 2:25 AM, Marko Rauhamaa wrote: >> I don't know Python's asyncio as it's very new and I haven't yet found >> an excuse to use it, but with Pike, I just engage backend mode, set >> callbacks on the appropriate socket/file/port objects, and let things >> happen perfectly. > >

Re: threading

Chris Angelico : > For a start, nearly everything Marko just posted should be dealt with > by your library. Let's not kid ourselves: it is hard to get any reactive system right. > I don't know Python's asyncio as it's very new and I haven't yet found > an excuse to use it, but with Pike, I just

Re: threading

Sturla Molden : > And exactly how is getting all of this correct any easier than just > using threads and blocking i/o? > > I'd like to see the programmer who can get all of this correct, but > has no idea how to use a queue og mutex without deadlocking. My personal experience is that it is easie

Re: threading

On Fri, Apr 11, 2014 at 1:24 AM, Sturla Molden wrote: > And exactly how is getting all of this correct any easier than just using > threads and blocking i/o? For a start, nearly everything Marko just posted should be dealt with by your library. I don't know Python's asyncio as it's very new and I

Re: threading

Marko Rauhamaa wrote: > Other points: > > * When you wake up from select() (or poll(), epoll()), you should treat >it as a hint. The I/O call (accept()) could still raise >socket.error(EAGAIN). > > * The connections returned from accept() have to be individually >registered with s

Re: threading

On 4/9/14 12:52 PM, Chris Angelico wrote: People with a fear of threaded programming almost certainly never grew up on OS/2. :) I learned about GUI programming thus: Write your synchronous message handler to guarantee that it will return in an absolute maximum of 0.1s, preferably a lot less. If

Re: threading

In article <87wqexmmuc@elektro.pacujo.net>, Marko Rauhamaa wrote: > * When you wake up from select() (or poll(), epoll()), you should treat >it as a hint. The I/O call (accept()) could still raise >socket.error(EAGAIN). People often misunderstand what select() does. The common mis

Re: threading

"Frank Millman" : > You seem to be suggesting that I set the socket to 'non-blocking', use > select() to determine when a client is trying to connect, and then > call 'accept' on it to create a new connection. Yes. > If so, I understand your point. The main loop changes from 'blocking' > to 'non

Re: threading

On Thu, Apr 10, 2014 at 9:10 PM, Frank Millman wrote: > You seem to be suggesting that I set the socket to 'non-blocking', use > select() to determine when a client is trying to connect, and then call > 'accept' on it to create a new connection. Right! That's about how it goes. Of course, for pro

Re: threading

"Chris Angelico" wrote in message news:CAPTjJmoWaHPZk=DAxbfJ=9ez2aj=4yf2c8wmbryof5vgn6e...@mail.gmail.com... > On Thu, Apr 10, 2014 at 7:17 PM, Frank Millman wrote: >> The current version of my program uses HTTP. As I understand it, a client >> makes a connection and submits a request. The serv

Re: threading

On Thu, Apr 10, 2014 at 7:17 PM, Frank Millman wrote: > The current version of my program uses HTTP. As I understand it, a client > makes a connection and submits a request. The server processes the request > and returns a result. The connection is then closed. > > In this scenario, does async app

Re: threading

"Chris Angelico" wrote in message news:CAPTjJmq2xx_WG2ymCC0NNqisDO=dnnjhnegpid3de+xeiy5...@mail.gmail.com... > On Thu, Apr 10, 2014 at 12:30 AM, Frank Millman > wrote: >> >>> How does one distinguish betwen 'blocking' and 'non-blocking'? Is it either/or, or is it some arbitrary timeo

Re: threading

On Thu, Apr 10, 2014 at 6:23 PM, Mark Lawrence wrote: > On 10/04/2014 00:53, Roy Smith wrote: >> Natural language is a wonderfully expressive thing. I open the window, >> stick my head out, look up at the sky, and say, "Raining". Forget the >> pronoun, I don't even have a verb. And yet everybod

Re: threading

On 10/04/2014 00:53, Roy Smith wrote: Natural language is a wonderfully expressive thing. I open the window, stick my head out, look up at the sky, and say, "Raining". Forget the pronoun, I don't even have a verb. And yet everybody understands exactly what I mean. In the UK you can stay in

Re: threading

On Thu, Apr 10, 2014 at 1:44 PM, Steven D'Aprano wrote: >> Now, before i utterly destroy you, we must first *ALL* take a lesson in >> linguistics. > > Oh noes! I'm going to be destroyed by Rick, Super-Genius! I'll send him my business card as a salesman for Acme. Easiest job in the world - just s

Re: threading

On Wed, 09 Apr 2014 08:51:09 -0700, Rick Johnson wrote: > On Wednesday, April 9, 2014 8:50:59 AM UTC-5, Neil D. Cerutti wrote: >> [...] >> Plus Rufus Xavier Sasparilla disagrees with it. > > If you think you're going to argue in such an implicit manner as to the > benefits of pronouns, then you s

Re: threading

On Thu, Apr 10, 2014 at 12:43 PM, Steven D'Aprano wrote: > You cannot use plane English! Cleared for takeoff... ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: threading

On Wed, 09 Apr 2014 19:53:26 -0400, Roy Smith wrote: > Natural language is a wonderfully expressive thing. I open the window, > stick my head out, look up at the sky, and say, "Raining". Forget the > pronoun, I don't even have a verb. And yet everybody understands > exactly what I mean. Not ev

Re: threading

On Thu, Apr 10, 2014 at 9:44 AM, Dennis Lee Bieber wrote: > On Wed, 9 Apr 2014 23:47:04 +1000, Chris Angelico > declaimed the following: > >>won't block. You might think "Duh, how can printing to the screen >>block?!?", but if your program's output is being piped into something >>else, it most ce

Re: threading

On 2014.04.09 18:53, Roy Smith wrote: > It's even more ambiguous in Spanish. Esta lloviendo. Not only do you > get to intuit the referrent, you get to intuit the pronoun too :-) And in this particular instance, you have to figure out that 'está' (verb) was meant instead of 'esta' (adjective). :

  1   2   3   4   5   >