I am using workers every time when is something to do. I can't access the DOM from worker, but I can access it from main program and pass that information to one worker to do what is need it and return the result.
I use the main program body only to interact with the user: get and sent data to user. Any data processing is done in workers. I have many workers for every single thing that I need. In this way I keep the interface responsive for the user 100% of the time. On Aug 7, 8:14 pm, jungleforce <[email protected]> wrote: > LOL, yeah old habits die hard. I'm actually working on moving into a > Javascript server. I would like to play with Google's GWT more. PHP > has been so easy for small, quick projects. But they always grow into > something that deserves better organization. > > I have to admit that I've been quite impressed with the workers as > well. I was hoping that I could get away with blindly using db calls > as well, but clearly that was pushing my luck. > > I'm just curious, since you can't access the DOM and you have to be so > careful about DB work, that doesn't really leave a lot of use for the > workers, what kind of stuff do you use them for? > > On Aug 5, 4:50 am, Eduard Martini <[email protected]> wrote: > > > I really like how the workers are now, are not exactly as threads and > > do their job. If you make specialized workers for each job from your > > application, all will run smoothly and never go in "unresponsive > > script" error. I really like that I can to just "pass" some work from > > main javascript code to a worker and don't care about it. When it is > > done, I will get a message. > > > Yes, that can be made more complex to have transactions with isolation > > levels and waiting queue for lock releasing, but I think this is > > beyond of scope of gears. > > > And why are you still on PHP? I tried RoR 3 years ago and never looked > > back at PHP. > > > On Aug 4, 6:35 pm, jungleforce <[email protected]> wrote: > > > > Opps, I meant to add sample code to the last post. > > > > ie. > > > sql = 'SELECT rowid,* FROM test WHERE col1 = ?'; > > > rs = db.execute(sql,['a']); > > > while(rs.isValidRow())[ > > > sql = 'UPDATE test SET col2 = ? WHERE rowid = ?'; > > > db.execute(sql,['1',rs.fielByName('rowid')]); > > > > rs.next();} > > > > rs.close(); > > > > In a statement like this, in general I shouldn't have a problem except > > > when I have 2 threads trying to do the same thing, which is when I > > > should push all db access code into a single thread. Right? I'm used > > > to programming in PHP where I can pretty much get away with murder. > > > It's been a long time since I've had to be careful about threading. > > > > I'm probably going to get flamed for this one, however, I wonder if > > > the db commands couldn't be make thread safe so that programmers > > > wouldn't have to repeat this code pattern. > > > > BTW, thanks for the feedback. > > > > On Aug 4, 10:58 am, jungleforce <[email protected]> wrote: > > > > > Within one thread if I do a SELECT call and than UPDATE or DELETE > > > > records from the same table as the SELECT call that I'm iterating > > > > through, I shouldn't have a problem right? It's only when another > > > > thread also tries to make a request while another thread is iterating > > > > through the database and making changes that I would run into trouble, > > > > right? It's usually on an UPDATE statement that I run into lock > > > > problems. > > > > > ie.
