[Bf-committers] Re: listener object

Wed May 11 16:04:14 CEST 2005

As long as the event queue were protected by a semaphore (easy to 
implement if there is a single function for placing items in the 
queue), It seems harmless to create a socket listener, in it's own 
thread, that could take events from a network queue and drop them into 
the blender event queue.  This function would be great for writing an 
external program for regression testing, if all blender/user 
interaction could be simulated through events.

My only advice is to proceed with caution.  One of the hard and fast 
rules of programming is "if anything can go wrong, it will".  If there 
is a single set of data that is accessed from two threads without a 
semaphore, or some other atomic protection scheme to control access, 
there will be a problem.  Proceed with caution.

Douglas Toltzman, Oak Street Software, Inc.

On May 11, 2005, at 8:14 AM, Martin DeMello wrote:

> Hi Douglas,
>
> I was referring to the fact that the data coming over the socket
> server will never be relied upon, merely its presence or absence.
> Scripts will run in their own threads, yes, but don't they do that
> anyway? I was essentially hoping that the scriptlink mechanism already
> had safety guards in place to prevent the corruption of Blender data
> by multiple scripts trying to read/write it, which is why I said there
> shouldn't be any new concurrency issues introduced, but I'm rather new
> to Blender programming so I'm happy to be told where I'm going wrong.
>
> martin
>
> On 5/11/05, Douglas Toltzman <doug at oakstreetsoftware.com> wrote:
>> I'm not sure I understand your plan, but the only way I can see for 
>> you
>> to avoid concurrency issues would be to post an event for the main 
>> loop
>> to act upon.  That may be what you are proposing.  Otherwise, if you
>> kick off another script, it will be running in a new thread, or in the
>> socket-server's thread.
>>
>> Either way, if you've already considered it, then I guess I need not
>> bother you about it.
>>
>> Douglas Toltzman, Oak Street Software, Inc.
>>
>> On May 11, 2005, at 7:45 AM, Martin DeMello wrote:
>>
>>> I thought of that - the use case I settled on involves the socket
>>> doing nothing other than triggering a python script and being 
>>> flushed.
>>> If the python script wants data over the network it has to open an
>>> entirely separate socket and communicate over that (i.e. the Blender
>>> event loop will no longer be involved in the transaction). The
>>> triggered scripts will behave as ordinary scriptlink-type scripts, so
>>> the same caveats as normal apply to them, but I don't think this is
>>> going to introduce any new concurrency issues.
>>>
>>> martin
>>>
>>> On 5/11/05, Douglas Toltzman <doug at oakstreetsoftware.com> wrote:
>>>> I have only one caveat to add to this discussion.  Adding a
>>>> socket/network interface to Blender will result in at least one more
>>>> thread of execution.  If it is designed to handle multiple 
>>>> requesters,
>>>> it will add one thread per client, at least.  Since Blender isn't 
>>>> yet
>>>> multi-threaded, there will be no way for the client threads to know
>>>> the
>>>> exact state of the data that is being read.  i.e. the data could be 
>>>> in
>>>> a transient state because it is being manipulated by the main 
>>>> thread.
>>>>
>>>> Douglas Toltzman, Oak Street Software, Inc.
>>>> voice: 910-526-5938
>>>> http://www.oakstreetsoftware.com/
>>>>
>>>> On May 11, 2005, at 5:42 AM, Toni Alatalo wrote:
>>>>
>>>>>> Ton Roosendaal wrote:
>>>>>>> I don't think an "Always scrptlink" is the way to go... we should
>>>>>>> keep
>>>>>>> things fully event based in Blender's UI.
>>>>>
>>>>> but, as said in the posts that followed (by Martin & Campbell),
>>>>> that was not about the UI, but having an invisible daemon running 
>>>>> in
>>>>> Blender, serving requests coming from outside (e.g. information 
>>>>> about
>>>>> what material some object is using etc., if i understood 
>>>>> correctly).
>>>>>
>>>>> i agree that the 'always' scriptlink feels strange, and liked
>>>>> Martin's
>>>>> idea of a 'onIncomingSockedData' scriptlink or something like that.
>>>>> as
>>>>> far
>>>>> as i can see the only benefit of the 'always' one would be that no
>>>>> socket
>>>>> handling would be needed on the C side of Blender, which would only
>>>>> need
>>>>> to activate the scripts from the mainloop using some sort of timer
>>>>> perhaps. that is how it has always worked on the game engine side,
>>>>> where
>>>>> there actually is an 'always' sensor, that has been used to 
>>>>> implement
>>>>> network servers within Blender too - doing all the networking in
>>>>> Python
>>>>> only.
>>>>>
>>>>> first i thought that the 'always' scriptlink might be useful for
>>>>> other
>>>>> kind of background-processing python scripts too, but those 
>>>>> probably
>>>>> are
>>>>> better off as event-driven (perhaps with SceneChanged or something
>>>>> like
>>>>> that added if needed, but that's irrelevant to this discussion).
>>>>>
>>>>> did something come out of this already, what did Martin&co choose 
>>>>> to
>>>>> do?
>>>>> .. oh just noticed that he's posting follow-ups to bf-python, i'll 
>>>>> be
>>>>> looking there and wont post more here anymore either.
>>>>>
>>>>>>> Would it be possible for Python to add callbacks instead? 
>>>>>>> Meaning,
>>>>>>> it
>>>>>>> assigns to an external program the means to insert events in the
>>>>>>> main
>>>>>>> queue, which is then being handled by another script. Could also
>>>>>>> be a
>>>>>>> means to plugin input devices.
>>>>>
>>>>> i guess that is possible. and as Martin and others saw, sockets are
>>>>> an
>>>>> ok
>>>>> way for it. just the mechanism to enable bpython scripts to receive
>>>>> socket
>>>>> connections is needed, for example by making either the 'always' /
>>>>> 'onTimer' or 'onIncomingSocketData' scriptlinks. right?
>>>>>
>>>>>>> -Ton-
>>>>>
>>>>> ~Toni
>>>>>
>>>>>>> On 6 May, 2005, at 13:21, Martin DeMello wrote:
>>>>>>>
>>>>>>>> On 5/6/05, Martin DeMello <martindemello at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I'd like to add a "listener" object to blender, to allow a 
>>>>>>>>> script
>>>>>>>>> to
>>>>>>>>> be triggered by an external program writing to a socket. (Not
>>>>>>>>> necessarily proposing this be added to blender proper, but it
>>>>>>>>> would be
>>>>>>>>> very useful for my own copy.) Is this an intrinsically 
>>>>>>>>> dangerous
>>>>>>>>> idea?
>>>>>>>>> (i.e. could it cause instability or crashes in blender?) If 
>>>>>>>>> not,
>>>>>>>>> how
>>>>>>>>> would I go about doing it? (i.e., where in the code should I be
>>>>>>>>> looking to add something like this?)
>>>>>>>> Also, antont suggested on IRC that an 'always' scriptlink that
>>>>>>>> activated once every timer tick would be another nice way to
>>>>>>>> accomplish this. The triggered python script could then poll the
>>>>>>>> socket.
>>>>>>>>
>>>>>>>> martin
>>>>>
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at projects.blender.org
>>>>> http://projects.blender.org/mailman/listinfo/bf-committers
>>>>>
>>>>
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at projects.blender.org
>>>> http://projects.blender.org/mailman/listinfo/bf-committers
>>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at projects.blender.org
>>> http://projects.blender.org/mailman/listinfo/bf-committers
>>>
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
>> http://projects.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>