On Apr 28, 11:49 pm, David Bolen wrote:
> Vsevolod writes:
> > On Apr 27, 11:31 pm, David Bolen wrote:
> >> I'm curious - do you know what happens if threading is implemented as
> >> a native OS thread and it's stuck in an I/O operation that is blocked?
> >> How does the Lisp interpreter/runtime
David Bolen wrote:
Vsevolod writes:
On Apr 27, 11:31 pm, David Bolen wrote:
I'm curious - do you know what happens if threading is implemented as a
native OS thread and it's stuck in an I/O operation that is blocked? How
does the Lisp interpreter/runtime gain control again in order to execut
Vsevolod writes:
> On Apr 27, 11:31 pm, David Bolen wrote:
>> I'm curious - do you know what happens if threading is implemented as
>> a native OS thread and it's stuck in an I/O operation that is blocked?
>> How does the Lisp interpreter/runtime gain control again in order to
>> execute the spe
In article <9a827369-b36f-4a86-870a-e5a505e34...@q33g2000pra.googlegroups.com>,
Vsevolod wrote:
>On Apr 27, 8:18 pm, a...@pythoncraft.com (Aahz) wrote:
>>
>> If you want to talk about Python and problems you're running into, you
>> should start a new thread.
>
>I'm not at that level of proficien
On Apr 27, 11:31 pm, David Bolen wrote:
> I'm curious - do you know what happens if threading is implemented as
> a native OS thread and it's stuck in an I/O operation that is blocked?
> How does the Lisp interpreter/runtime gain control again in order to
> execute the specified function? I guess
On Apr 27, 8:18 pm, a...@pythoncraft.com (Aahz) wrote:
> That's because there's no response to make; the original post was a joke,
> and trying to have a serious discussion about it rarely excites people.
In every joke there's a grain of truth. And usenet is precisely for
that thing -- discussions
David Bolen writes:
> I'm curious - do you know what happens if threading is implemented as
> a native OS thread and it's stuck in an I/O operation that is blocked?
> How does the Lisp interpreter/runtime gain control again in order to
> execute the specified function? I guess on many POSIX-ish
>
Vsevolod writes:
> "This should be used with caution: it is implementation-defined
> whether the thread runs cleanup forms or releases its locks first."
> This doesn't mean deprecated. It means: implementation-dependent. For
> example in SBCL: "Terminate the thread identified by thread, by
> caus
In article <22272831-8d11-42d6-a587-9a2ab4712...@p6g2000pre.googlegroups.com>,
Vsevolod wrote:
>
>Yet there was no response to my point, that the original example was
>not realistically depicting the Lisp world, while more characteristic
>of the Python one.
That's because there's no response to
On Apr 27, 7:16 pm, a...@pythoncraft.com (Aahz) wrote:
> Did you see my comment about Java? This particular issue has little to
> do with Python. I won't disagree that what you're describing is
> sometimes a problem in the Python community, but you're picking the
> wrong issue to claim its releva
In article <42cebb2b-0361-416c-8932-9371da50a...@y6g2000prf.googlegroups.com>,
Vsevolod wrote:
>
>As well I'd like to outline, that, IMO, your answer exhibits the
>common attitude among pythonistas: everything should be done in one
>true way, which is the best option (and that is how it's impleme
On Mon, Apr 27, 2009 at 11:55 AM, Vsevolod wrote:
>
> As well I'd like to outline, that, IMO, your answer exhibits the
> common attitude among pythonistas: everything should be done in one
> true way, which is the best option (and that is how it's implemented
> in the current version of the langu
On Apr 27, 2:17 pm, "Richard Brodie" wrote:
> "Vsevolod" wrote in message
>
> news:42cebb2b-0361-416c-8932-9371da50a...@y6g2000prf.googlegroups.com...
>
> > There's a common unification library -- bordeaux-threads --
> > that abstracts away implementation specifics. It's API includes
> > the func
"Vsevolod" wrote in message
news:42cebb2b-0361-416c-8932-9371da50a...@y6g2000prf.googlegroups.com...
> There's a common unification library -- bordeaux-threads --
> that abstracts away implementation specifics. It's API includes
> the function destroy-thread.
Which is deprecated, like the Jav
On Apr 27, 3:20 am, a...@pythoncraft.com (Aahz) wrote:
> In article
> <793a5176-ec2d-4ffd-b1e7-762077733...@v35g2000pro.googlegroups.com>,
>
> Vsevolod wrote:
> >On Apr 26, 6:28 pm, a...@pythoncraft.com (Aahz) wrote:
>
> >> The problem is that thread-killing (in the literal sense) doesn't work.
In article <793a5176-ec2d-4ffd-b1e7-762077733...@v35g2000pro.googlegroups.com>,
Vsevolod wrote:
>On Apr 26, 6:28 pm, a...@pythoncraft.com (Aahz) wrote:
>>
>> The problem is that thread-killing (in the literal sense) doesn't work.
>> Unlike processes, there's no thread-environment encapsulation at
On Apr 26, 6:28 pm, a...@pythoncraft.com (Aahz) wrote:
> The problem is that thread-killing (in the literal sense) doesn't work.
> Unlike processes, there's no thread-environment encapsulation at the OS
> level, which means that things don't get cleaned up properly. Even Java
> has mostly given up
In article ,
Vsevolod wrote:
>
>And let's look at my recent experience with Python: I wanted to
>implement a daemon process and stumbled at a simplest problem with
>threading: neither Thread, nor Threading module provides thread-
>killing possibility. Surely, I'm not so experienced in Python as i
18 matches
Mail list logo
